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-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers