Re: Assertion failure on UNLOGGED VIEW and SEQUENCE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Assertion failure on UNLOGGED VIEW and SEQUENCE
Date
Msg-id 21212.1298041367@sss.pgh.pa.us
Whole thread Raw
In response to Re: Assertion failure on UNLOGGED VIEW and SEQUENCE  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Assertion failure on UNLOGGED VIEW and SEQUENCE  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Feb 18, 2011 at 6:42 AM, Itagaki Takahiro
>> The most easiest fix would be preventing them in parser level.

> Well, that sucks.  I had intended for that to be disallowed at the
> parser level, but obviously I fail.  It seems that disallowing this in
> the parser will require duplicating the OptTemp production.  Or
> alternatively we can just add an error check to the CREATE VIEW and
> CREATE SEQUENCE productions, i.e.

> if ($4 == RELPERSISTENCE_UNLOGGED)
>     ereport(ERROR, ...);

> I am somewhat leaning toward the latter option, to avoid unnecessarily
> bloating the size of the parser tables, but I can do it the other way
> if people prefer.

If by the first option you mean causing the failure report to be "syntax
error" rather than anything more specific, then I agree that option
sucks.  I'd actually vote for putting the error test somewhere in
statement execution code, well downstream of gram.y.  The parser's job
is to produce a parse tree, not to encapsulate knowledge about which
combinations of options are supported.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: About the performance of startup after dropping many tables
Next
From: Gurjeet Singh
Date:
Subject: Re: Fix for Index Advisor related hooks