Обсуждение: BUG #15535: psql: \copy: parse error at...

The following bug has been logged on the website:

Bug reference:      15535
Logged by:          jean-marc voillequin
Email address:      jean-marc.voillequin@moodys.com
PostgreSQL version: 10.3
Operating system:   windows 7
Description:

When I run the following copy command under psql:

\copy pg_tables /*(*/ to 'test';

I get:
\copy: parse error at "/*"

The comment /*(*/ is not ignored.

The following bug has been logged on the website:

Bug reference:      15535
Logged by:          jean-marc voillequin
Email address:      jean-marc.voillequin@moodys.com
PostgreSQL version: 10.3
Operating system:   windows 7
Description:       

When I run the following copy command under psql:

\copy pg_tables /*(*/ to 'test';

I get:
\copy: parse error at "/*"

The comment /*(*/ is not ignored.

SIMPLE=> \copy (select * from /*comment*/ pg_tables) to 'test';

COPY 76

 

SIMPLE=> \copy (select * from /*comment with a closing parenthesis)*/ pg_tables) to 'test';

\copy: parse error at "*/"

 

Only comments without parenthesis are supported?

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Wednesday, December 5, 2018, Voillequin, Jean-Marc <
> Jean-Marc.Voillequin@moodys.com> wrote:
>> SIMPLE=> \copy (select * from /*comment with a closing parenthesis)*/
>> pg_tables) to 'test';
>> \copy: parse error at "*/"

> psql \copy doesn't understand comments.

More precisely, psql backslash commands in general have no provision
for comments.  Everything from the backslash to the end of the line
(or the next backslash command) is live command text.  If \copy had
a smarter parser for the embedded SELECT command, maybe that would
recognize SQL comments ... but it doesn't.

There was a proposal awhile back to provide a variant of \copy
that works more like \g, so you'd enter something like

COPY (SELECT ...) TO STDOUT
\copyto somefile

which'd be way more flexible --- the COPY command wouldn't have to
fit on one line, for one thing.  But I don't think that's gone
anywhere yet.

            regards, tom lane

My select statement to export was a 26K chars with several /* */ comments, and I could not imagine such issue.

Thank you guys.


-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Wednesday, December 05, 2018 4:05 PM
To: David G. Johnston <david.g.johnston@gmail.com>
Cc: Voillequin, Jean-Marc <Jean-Marc.Voillequin@moodys.com>; pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15535: psql: \copy: parse error at...



CAUTION: This email originated from outside of Moody's. Do not click links or open attachments unless you recognize the
senderand know the content is safe. 



"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Wednesday, December 5, 2018, Voillequin, Jean-Marc <
> Jean-Marc.Voillequin@moodys.com> wrote:
>> SIMPLE=> \copy (select * from /*comment with a closing parenthesis)*/
>> pg_tables) to 'test';
>> \copy: parse error at "*/"

> psql \copy doesn't understand comments.

More precisely, psql backslash commands in general have no provision for comments.  Everything from the backslash to
theend of the line (or the next backslash command) is live command text.  If \copy had a smarter parser for the
embeddedSELECT command, maybe that would recognize SQL comments ... but it doesn't. 

There was a proposal awhile back to provide a variant of \copy that works more like \g, so you'd enter something like

COPY (SELECT ...) TO STDOUT
\copyto somefile

which'd be way more flexible --- the COPY command wouldn't have to fit on one line, for one thing.  But I don't think
that'sgone anywhere yet. 

            regards, tom lane

-----------------------------------------

Moody's monitors email communications through its networks for regulatory compliance purposes and to protect its
customers,employees and business and where allowed to do so by applicable law. The information contained in this e-mail
message,and any attachment thereto, is confidential and may not be disclosed without our express permission. If you are
notthe intended recipient or an employee or agent responsible for delivering this message to the intended recipient,
youare hereby notified that you have received this message in error and that any review, dissemination, distribution or
copyingof this message, or any attachment thereto, in whole or in part, is strictly prohibited. If you have received
thismessage in error, please immediately notify us by telephone, fax or e-mail and delete the message and all of its
attachments.Every effort is made to keep our network free from viruses. You should, however, review this e-mail
message,as well as any attachment thereto, for viruses. We take no responsibility and have no liability for any
computervirus which may be transferred via this e-mail message. 

This email was sent to you by Moody’s Investors Service EMEA Limited
Registered office address:
One Canada Square
Canary Wharf
London, E14 5FA
Registered in England and Wales No: 8922701

-----------------------------------------

    Tom Lane wrote:

> There was a proposal awhile back to provide a variant of \copy
> that works more like \g, so you'd enter something like
>
> COPY (SELECT ...) TO STDOUT
> \copyto somefile
>
> which'd be way more flexible --- the COPY command wouldn't have to
> fit on one line, for one thing.  But I don't think that's gone
> anywhere yet.

That would be the proof-of-concept patch posted a few weeks ago here:
https://www.postgresql.org/message-id/15dadc39-e050-4d46-956b-dcc4ed098753@manitou-mail.org

There didn't seem to be much of community buy-in for this idea, so I've it
let rest
for the moment. On one hand, it solves actual problems such as the one
mentioned in this bug report, on the other hand I can feel the discomfort
of having 3 forms of \copy, in addition to COPY, and that maybe it would
create more confusion than benefits, overall.


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

"Daniel Verite" <daniel@manitou-mail.org> writes:
> Tom Lane wrote:
>> There was a proposal awhile back to provide a variant of \copy
>> that works more like \g, so you'd enter something like
>>
>> COPY (SELECT ...) TO STDOUT
>> \copyto somefile
>>
>> which'd be way more flexible --- the COPY command wouldn't have to
>> fit on one line, for one thing.  But I don't think that's gone
>> anywhere yet.

> That would be the proof-of-concept patch posted a few weeks ago here:
> https://www.postgresql.org/message-id/15dadc39-e050-4d46-956b-dcc4ed098753@manitou-mail.org

> There didn't seem to be much of community buy-in for this idea, so I've it
> let rest
> for the moment. On one hand, it solves actual problems such as the one
> mentioned in this bug report, on the other hand I can feel the discomfort
> of having 3 forms of \copy, in addition to COPY, and that maybe it would
> create more confusion than benefits, overall.

Yeah, that is an issue all right.  It occurs to me that for the COPY TO
side, we don't really need any new command: we could just make \g work
for that case.  (Testing, it seems that plain "\g" works fine already,
but "\g foo" fails to redirect the COPY output, which seems to me to
be arguably a bug as well as lack of useful functionality.)

That approach does nothing for COPY FROM, though.  On the other hand,
it's not needed nearly as bad for COPY FROM, since you can't put a
giant sub-SELECT into that.

            regards, tom lane

    Tom Lane wrote:

> Yeah, that is an issue all right.  It occurs to me that for the COPY TO
> side, we don't really need any new command: we could just make \g work
> for that case.  (Testing, it seems that plain "\g" works fine already,
> but "\g foo" fails to redirect the COPY output, which seems to me to
> be arguably a bug as well as lack of useful functionality.)
>
> That approach does nothing for COPY FROM, though.  On the other hand,
> it's not needed nearly as bad for COPY FROM, since you can't put a
> giant sub-SELECT into that.

Agreed. I will look into the problem of COPY OUT with \g filename
if you don't beat me to it.

Concerning \copyfrom, the most obvious use case is when the filename
has to be a variable, which \copy doesn't allow for.
But this one might be better solved by just improving \copy.


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

"Daniel Verite" <daniel@manitou-mail.org> writes:
> Tom Lane wrote:
>> Yeah, that is an issue all right.  It occurs to me that for the COPY TO
>> side, we don't really need any new command: we could just make \g work
>> for that case.  (Testing, it seems that plain "\g" works fine already,
>> but "\g foo" fails to redirect the COPY output, which seems to me to
>> be arguably a bug as well as lack of useful functionality.)
>> 
>> That approach does nothing for COPY FROM, though.  On the other hand,
>> it's not needed nearly as bad for COPY FROM, since you can't put a
>> giant sub-SELECT into that.

> Agreed. I will look into the problem of COPY OUT with \g filename
> if you don't beat me to it.

I wasn't volunteering to work on that, so have at it.

> Concerning \copyfrom, the most obvious use case is when the filename
> has to be a variable, which \copy doesn't allow for.
> But this one might be better solved by just improving \copy.

I wonder ... would it be outrageous for "\g foo" to be interpreted
as reading foo, not writing it, if what comes back from the server
is a CopyInResponse message rather than a query result or
CopyOutResponse?

No new commands that way, but maybe more potential for user confusion,
so I'm not sure if this is a good idea or not.

            regards, tom lane