On 26.05.2013 04:31, Simon Riggs wrote:
> This works fine...
> COPY pgbench_accounts TO '/tmp/acc' BINARY;
>
> This new format does not
> COPY pgbench_accounts FROM '/tmp/acc' (FORMAT BINARY);
> ERROR: syntax error at or near "BINARY" at character 47
>
> which looks like I've mistyped something. Until you realise that this
> statement gives a completely different error message.
>
> COPY pgbench_accounts FROM '/tmp/acc' (FORMAT anyname);
> ERROR: COPY format "anyname" not recognized
>
> and we also note that there are no examples in the docs, nor
> regression tests to cover this situation.
>
> So I conclude that this hasn't ever worked since it was introduced in 9.0.
>
> The cause is that there is an overlap between the old and the new COPY
> syntax, relating to the word BINARY. It's the grammar generating the
> error, not post parse analysis.
Hmm, the problem is that BINARY is a type_func_keyword, so it doesn't
match the ColId rule used to capture the format argument.
> My attempts to fix that look pretty ugly, so I'm not even going to
> post them. I can stop the error on binary by causing errors on csv and
> text, obviously not a fix. Any grammar based fix looks like it would
> restrict the list of formats, which breaks the orginal intention of
> the syntax change.
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"));
+ }
Am I missing something?
- Heikki
