Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work
Date
Msg-id 13862.1369584649@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@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



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Using indexes for partial index builds
Next
From: Bernd Helmle
Date:
Subject: Re: background worker and normal exit