Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work
От | Tom Lane |
---|---|
Тема | Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work |
Дата | |
Msg-id | 10844.1369665086@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work
Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work |
Список | 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 по дате отправления: