COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary)
ERROR: syntax error at or near "binary"
LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary)
^
********** Error **********
ERROR: syntax error at or near "binary"
SQL state: 42601
Character: 55
But if I use 'FORMAT text' or 'FORMAT csv' all is OK.
Suppose this happens because BINARY is not listed in
"unreserved_keyword" neither in "col_name_keyword parser" parser rules, but
listed in "type_func_name_keyword" instead.
--
With best wishes,
Pavel mailto:pavel@gf.microolap.com
Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary)
ERROR: syntax error at or near "binary"
LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary)
^********** Error **********
ERROR: syntax error at or near "binary"
SQL state: 42601
Character: 55But if I use 'FORMAT text' or 'FORMAT csv' all is OK.
Suppose this happens because BINARY is not listed in
"unreserved_keyword" neither in "col_name_keyword parser" parser rules, but
listed in "type_func_name_keyword" instead.
That seems pretty unfortunate. Of course, it works if you quote it:
COPY "tablename" TO STDOUT WITH (FORMAT "binary")
I assume it's not in unreserved_keyword because it would cause a
shift/reduce conflict elsewhere.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Hello, Alvaro.
You wrote:
AH> Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary)
ERROR: syntax error at or near "binary"
LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary)
^********** Error **********
ERROR: syntax error at or near "binary"
SQL state: 42601
Character: 55But if I use 'FORMAT text' or 'FORMAT csv' all is OK.
Suppose this happens because BINARY is not listed in
"unreserved_keyword" neither in "col_name_keyword parser" parser rules, but
listed in "type_func_name_keyword" instead.
AH> That seems pretty unfortunate. Of course, it works if you quote it:
AH> COPY "tablename" TO STDOUT WITH (FORMAT "binary")
AH> I assume it's not in unreserved_keyword because it would cause a
AH> shift/reduce conflict elsewhere.
Well, there are two ways:
1. Change documentation, so quoted or double quoted values are
accepted
2. Fix parser
--
With best wishes,
Pavel mailto:pavel@gf.microolap.com
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary)
ERROR: syntax error at or near "binary"
LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary)
^********** Error **********
ERROR: syntax error at or near "binary"
SQL state: 42601
Character: 55But if I use 'FORMAT text' or 'FORMAT csv' all is OK.
Suppose this happens because BINARY is not listed in
"unreserved_keyword" neither in "col_name_keyword parser" parser rules, but
listed in "type_func_name_keyword" instead.That seems pretty unfortunate. Of course, it works if you quote it:
COPY "tablename" TO STDOUT WITH (FORMAT "binary")
I assume it's not in unreserved_keyword because it would cause a
shift/reduce conflict elsewhere.
Yeah. In particular, it conflicts with the ancient copy syntax which
we still support for backwards compatibility with versions < 7.3. We
can fix the immediate problem with something like the attached.
(a) Should we do that?
(b) Should we back-patch it to 9.1 and 9.0?
(c) Should we consider removing compatibility with the ancient copy
syntax in 9.2, and de-reserving that keyword? (Given that the
workaround is this simple, I'm inclined to say "no", but could be
persuaded otherwise.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
allow-copy-format-binary.patchapplication/octet-stream; name=allow-copy-format-binary.patchDownload
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
***************
*** 2341,2351 **** copy_generic_opt_elem:
;
copy_generic_opt_arg:
! opt_boolean_or_string { $$ = (Node *) makeString($1); }
! | NumericOnly { $$ = (Node *) $1; }
! | '*' { $$ = (Node *) makeNode(A_Star); }
| '(' copy_generic_opt_arg_list ')' { $$ = (Node *) $2; }
! | /* EMPTY */ { $$ = NULL; }
;
copy_generic_opt_arg_list:
--- 2341,2352 ----
;
copy_generic_opt_arg:
! opt_boolean_or_string { $$ = (Node *) makeString($1); }
! | BINARY { $$ = (Node *) makeString("binary") }
! | NumericOnly { $$ = (Node *) $1; }
! | '*' { $$ = (Node *) makeNode(A_Star); }
| '(' copy_generic_opt_arg_list ')' { $$ = (Node *) $2; }
! | /* EMPTY */ { $$ = NULL; }
;
copy_generic_opt_arg_list:
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:I assume it's not in unreserved_keyword because it would cause a
shift/reduce conflict elsewhere.
Yeah. In particular, it conflicts with the ancient copy syntax which
we still support for backwards compatibility with versions < 7.3. We
can fix the immediate problem with something like the attached.
(a) Should we do that?
That seems like a horrid crock ...
regards, tom lane
On 07/05/2011 11:23 AM, Robert Haas wrote:
Yeah. In particular, it conflicts with the ancient copy syntax which
we still support for backwards compatibility with versions< 7.3. We
can fix the immediate problem with something like the attached.(a) Should we do that?
yes.
(b) Should we back-patch it to 9.1 and 9.0?
yes.
(c) Should we consider removing compatibility with the ancient copy
syntax in 9.2, and de-reserving that keyword? (Given that the
workaround is this simple, I'm inclined to say "no", but could be
persuaded otherwise.)
I'm inclined to say yes, but mainly because it's just old cruft. I don't
expect to be able,say, to load a pre-7.3 dump into a modern Postgres.
cheers
andrew
On Tue, Jul 5, 2011 at 11:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:I assume it's not in unreserved_keyword because it would cause a
shift/reduce conflict elsewhere.Yeah. In particular, it conflicts with the ancient copy syntax which
we still support for backwards compatibility with versions < 7.3. We
can fix the immediate problem with something like the attached.(a) Should we do that?
That seems like a horrid crock ...
Do you have something else to propose?
It's a crock we have used elsewhere, so there is some precedent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hello, Robert.
You wrote:
RH> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
RH> <alvherre@commandprompt.com> wrote:
Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary)
ERROR: �syntax error at or near "binary"
LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary)
� � � � � � � � � � � � � � � � � � � � � � � � � ^********** Error **********
ERROR: syntax error at or near "binary"
SQL state: 42601
Character: 55But if I use 'FORMAT text' or 'FORMAT csv' all is OK.
Suppose this happens because BINARY is not listed in
"unreserved_keyword" neither in "col_name_keyword parser" parser rules, but
listed in "type_func_name_keyword" instead.That seems pretty unfortunate. �Of course, it works if you quote it:
COPY "tablename" TO STDOUT WITH (FORMAT "binary")
I assume it's not in unreserved_keyword because it would cause a
shift/reduce conflict elsewhere.
RH> Yeah. In particular, it conflicts with the ancient copy syntax which
RH> we still support for backwards compatibility with versions < 7.3. We
RH> can fix the immediate problem with something like the attached.
This patch is ugly. Sorry, Robert, but it's true.
RH> (a) Should we do that?
RH> (b) Should we back-patch it to 9.1 and 9.0?
RH> (c) Should we consider removing compatibility with the ancient copy
RH> syntax in 9.2, and de-reserving that keyword? (Given that the
RH> workaround is this simple, I'm inclined to say "no", but could be
RH> persuaded otherwise.)
+1 for this. Pre-7.3 syntax is dead in fact for many years.
--
With best wishes,
Pavel mailto:pavel@gf.microolap.com
On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub <pavel@microolap.com> wrote:
RH> Yeah. In particular, it conflicts with the ancient copy syntax which
RH> we still support for backwards compatibility with versions < 7.3. We
RH> can fix the immediate problem with something like the attached.This patch is ugly. Sorry, Robert, but it's true.
No hard feelings here. If you, as the reporter of the problem, don't
feel that it's serious enough to warrant back-patching a fix, then I'm
not going to insist. However, if we don't do what I've proposed here,
then I think 8.4 and 9.0 and probably 9.1 are going to need to stay as
they are, because...
RH> (c) Should we consider removing compatibility with the ancient copy
RH> syntax in 9.2, and de-reserving that keyword? (Given that the
RH> workaround is this simple, I'm inclined to say "no", but could be
RH> persuaded otherwise.)+1 for this. Pre-7.3 syntax is dead in fact for many years.
...this is not something we're going to back-patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
... However, if we don't do what I've proposed here,
then I think 8.4 and 9.0 and probably 9.1 are going to need to stay as
they are, because...
RH> (c) Should we consider removing compatibility with the ancient copy
RH> syntax in 9.2, and de-reserving that keyword? �(Given that the
RH> workaround is this simple, I'm inclined to say "no", but could be
RH> persuaded otherwise.)+1 for this. Pre-7.3 syntax is dead in fact for many years.
...this is not something we're going to back-patch.
Given the lack of prior complaints, and the simplicity of the
double-quote workaround, I feel little need to have a back-patchable
fix.
regards, tom lane
Hello, Robert.
You wrote:
RH> On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub <pavel@microolap.com> wrote:
RH> Yeah. �In particular, it conflicts with the ancient copy syntax which
RH> we still support for backwards compatibility with versions < 7.3. �We
RH> can fix the immediate problem with something like the attached.This patch is ugly. Sorry, Robert, but it's true.
RH> No hard feelings here. If you, as the reporter of the problem, don't
RH> feel that it's serious enough to warrant back-patching a fix, then I'm
RH> not going to insist. However, if we don't do what I've proposed here,
RH> then I think 8.4 and 9.0 and probably 9.1 are going to need to stay as
RH> they are, because...
RH> (c) Should we consider removing compatibility with the ancient copy
RH> syntax in 9.2, and de-reserving that keyword? �(Given that the
RH> workaround is this simple, I'm inclined to say "no", but could be
RH> persuaded otherwise.)+1 for this. Pre-7.3 syntax is dead in fact for many years.
RH> ...this is not something we're going to back-patch.
Patches needed for 9.0 and 9.1 only, because this is new format
comparing with 8.x
--
With best wishes,
Pavel mailto:pavel@gf.microolap.com