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

Heikki Linnakangas <hlinnakangas(at)vmware(dot)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