Re: [HACKERS] COPY .... (FORMAT binary) syntax doesn't work

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] COPY .... (FORMAT binary) syntax doesn't work
Date: 2013-05-27 14:31:26
Message-ID: 10844.1369665086@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 26 May 2013 17:10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Stephen Frost 2013-05-27 15:25:08 Re: BUG #8176: problem with the "ALTER TYPE name RENAME TO new_name [ CASCADE | RESTRICT ]" syntax
Previous Message Stephen Frost 2013-05-27 14:25:09 Re: BUG #8176: problem with the "ALTER TYPE name RENAME TO new_name [ CASCADE | RESTRICT ]" syntax

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2013-05-27 14:32:49 Re: Processing long AND/OR lists
Previous Message Tom Lane 2013-05-27 14:25:46 Re: repeated warnings with 9.3 Beta 1 on windows