Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work
Date
Msg-id 10844.1369665086@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work  (Robert Haas <robertmhaas@gmail.com>)
Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 26 May 2013 17:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> More readable would be to invent an intermediate nonterminal falling
>> between ColId and ColLabel, whose expansion would be "IDENT |
>> unreserved_keyword | col_name_keyword | type_func_name_keyword", and
>> then replace ColId_or_Sconst with whatever-we-call-that_or_Sconst.
>> Any thoughts about a name for that new nonterminal?

> Do you think complicating the parser in that way is worth the trouble
> for this case? Could that slow down parsing?

It makes the grammar tables a bit larger (1% or so IIRC).  There would
be some distributed penalty for that, but probably not much.  Of course
there's always the slippery-slope argument about that.

> We don't actually have to fix it; clearly not too many people are
> bothered, since no complaints in 3 years. Documenting 'binary' seems
> better.

Well, my thought is there are other cases.  For instance:

regression=# create role binary;
ERROR:  syntax error at or near "binary"
LINE 1: create role binary;                   ^
regression=# create user cross;
ERROR:  syntax error at or near "cross"
LINE 1: create user cross;                   ^

If we don't have to treat type_func_name_keywords as reserved in these
situations, shouldn't we avoid doing so?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: repeated warnings with 9.3 Beta 1 on windows
Next
From: Christopher Browne
Date:
Subject: Re: Processing long AND/OR lists