Heikki Linnakangas <hlinnakan...@vmware.com> writes:
> On 26.05.2013 04:31, Simon Riggs wrote:
>> This new format does not [work:]
>> COPY pgbench_accounts FROM '/tmp/acc' (FORMAT BINARY);
>> ERROR: syntax error at or near "BINARY" at character 47
> This seems to work:
> --- a/src/backend/parser/gram.y
> +++ b/src/backend/parser/gram.y
> @@ -2528,3 +2528,7 @@ copy_generic_opt_elem:
> {
> $$ = makeDefElem($1, $2);
> }
> + | ColLabel BINARY
> + {
> + $$ = makeDefElem($1, (Node *)
> makeString("binary"));
> + }
That only fixes things for the specific case of FORMAT BINARY. I think
it would be better to generalize ColId_or_Sconst. This one-liner works,
but it's pretty ugly:
*** gram.y~ Sun May 26 11:58:42 2013
--- gram.y Sun May 26 12:00:03 2013
*************** opt_encoding:
*** 1548,1553 ****
--- 1548,1554 ----
ColId_or_Sconst:
ColId
{ $$ = $1; }
+ | type_func_name_keyword
{ $$ = pstrdup($1); }
| Sconst
{ $$ = $1; }
;
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?
BTW, I tried just replacing ColId with ColLabel here, and that *almost*
works, but there are some places where we can see either ColId_or_Sconst
or DEFAULT. I don't know of any sane way to express "all reserved
keywords except DEFAULT" to bison, so the best we can realistically do
is to accept all not-fully-reserved keywords in these places.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
