Lists: | pgsql-bugspgsql-hackers |
---|
From: | Pavel Golub <pavel(at)microolap(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 14:52:06 |
Message-ID: | 6510382810.20110705175206@gf.microolap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
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(at)gf(dot)microolap(dot)com
From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Pavel Golub <pavel(at)gf(dot)microolap(dot)com> |
Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 15:06:42 |
Message-ID: | 1309878337-sup-685@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
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.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From: | Pavel Golub <pavel(at)microolap(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 15:13:21 |
Message-ID: | 1564444906.20110705181321@gf.microolap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
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: 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.
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(at)gf(dot)microolap(dot)com
From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Pavel Golub <pavel(at)gf(dot)microolap(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 15:23:11 |
Message-ID: | CA+TgmoZebb5-8cnoTdNnCz3=AsqrFkzTuoK2FZAEbe3+rnF42w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)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.
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
Attachment | Content-Type | Size |
---|---|---|
allow-copy-format-binary.patch | application/octet-stream | 862 bytes |
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pavel Golub <pavel(at)gf(dot)microolap(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 15:30:04 |
Message-ID: | 3533.1309879804@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)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
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pavel Golub <pavel(at)gf(dot)microolap(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 15:34:36 |
Message-ID: | 4E132F0C.8090606@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
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
From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pavel Golub <pavel(at)gf(dot)microolap(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 15:34:47 |
Message-ID: | CA+TgmoZZWe+iJU6Q0DeWpGUWtY7a8rHdx30sBjJvysNgs6g9CQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
On Tue, Jul 5, 2011 at 11:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
>> <alvherre(at)commandprompt(dot)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
From: | Pavel Golub <pavel(at)microolap(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 15:37:15 |
Message-ID: | 1991135552.20110705183715@gf.microolap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
Hello, Robert.
You wrote:
RH> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
RH> <alvherre(at)commandprompt(dot)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:pavel(at)gf(dot)microolap(dot)com
From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Pavel Golub <pavel(at)gf(dot)microolap(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 15:40:49 |
Message-ID: | CA+TgmobRdj75osiVFdaHDL9C_mkjEpd1RoRmF+vY+EWicW748g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub <pavel(at)microolap(dot)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
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Pavel Golub <pavel(at)gf(dot)microolap(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 15:50:51 |
Message-ID: | 13623.1309881051@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From: | Pavel Golub <pavel(at)microolap(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary" |
Date: | 2011-07-05 16:02:13 |
Message-ID: | 1204438484.20110705190213@gf.microolap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs pgsql-hackers |
Hello, Robert.
You wrote:
RH> On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub <pavel(at)microolap(dot)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(at)gf(dot)microolap(dot)com