Hello, Robert. You wrote:
RH> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera RH> <alvhe...@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: 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. >> >> 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:pa...@gf.microolap.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
