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