From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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: [BUGS] COPY .... (FORMAT binary) syntax doesn't work |
Date: | 2013-06-01 18:36:47 |
Message-ID: | CA+U5nMK4enNSQxL-o6oQw3DTvie6eF5fZ-bOxxwO21U1Qn_DNA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 27 May 2013 15:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?
Seems reasonable argument, so +1. Sorry for delayed reply.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2013-06-01 19:04:13 | Re: BUG #8192: On very large tables the concurrent update with vacuum lag the hot_standby replica |
Previous Message | Kevin Grittner | 2013-06-01 17:49:56 | Re: BUG #8197: Error Message When trying to install PS8.1 |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-06-01 18:48:55 | Re: Freezing without write I/O |
Previous Message | Simon Riggs | 2013-06-01 18:34:15 | Re: Combo xids |