Kevin Grittner <kgri...@ymail.com> writes:
> Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Having said that, I don't think I believe your analysis of why
>> this doesn't work.
> Well, it wouldn't be the first time you've seen a better way to do
> something in flex than I was able to see. Taking just the gram.y
> part of the change which implemented this, and omitting the change
> in reservedness of MATERIALIZED, I have:
> - TRUNCATE opt_table relation_expr_list opt_restart_seqs
> opt_drop_behavior
> + TRUNCATE trunc_type relation_expr_list opt_restart_seqs
> opt_drop_behavior
> +trunc_type:
> + TABLE { $$ = OBJECT_TABLE; }
> + | MATERIALIZED VIEW { $$ = OBJECT_MATVIEW; }
> + | /*EMPTY*/ { $$ = OBJECT_UNSPECIFIED; }
> + ;
Yeah, this is a standard gotcha when working with unreserved keywords.
You can't factor it like that because then the parser is required to
make a shift-reduce decision (on whether to reduce trunc_type to empty)
before it can "see past" the first word. So for instance given
TRUNCATE MATERIALIZED ...
^
the parser has to make that decision when it can't see past the word
"MATERIALIZED" and so doesn't know what comes after it.
The way to fix it is to not try to use the sub-production but spell it
all out:
TRUNCATE TABLE relation_expr_list ...
| TRUNCATE MATERIALIZED VIEW relation_expr_list ...
| TRUNCATE relation_expr_list ...
Now the parser doesn't have to make any shift-reduce decision until
after it can "see past" the first identifier. It's a bit tedious
but beats making a word more reserved than it has to be.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
