Re: unexpected psql "feature" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: unexpected psql "feature"
Date
Msg-id 6255.1468451554@sss.pgh.pa.us
Whole thread Raw
In response to Re: unexpected psql "feature"  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: unexpected psql "feature"  (Geoff Winkless <pgsqladmin@geoff.dj>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Now, I think requesting psql not to split query strings is a good
> feature, but having it depend on using \; instead of ; seems way too
> obscure.  If we want to offer that choice, I propose we do it via some
> properly designed mechanism rather than being a random emergent
> characteristic falling out of a bunch of historical coincidences.

I think it was designed to do that; if you look at the code in psqlscan.l
that causes this to happen, it's clearly intentional not a "random
emergent characteristic".

Personally, I'm fine with documenting this behavior and having done.
What I don't like is Fabien's suggestion that we alter the behavior.
It's possible that that'll break existing applications, and the argument
that printing rather than discarding the PQresult is better seems pretty
weak anyway.  Discarding a PQresult seems like it would have some uses.

Worth noting by the way is thatselect 1 \; select 2;
has the same behavior aspsql -c 'select 1; select 2;'
since in both cases the whole string is sent in one PQexec.  I wonder
whether promoting \; to a recognized and documented behavior would
allow us to get away with converting -c strings to normal parsing
behavior, as was discussed and then rejected on compatibility grounds
not too long ago.  People who need to keep the old behavior could do so
by putting in backslashes.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: unexpected psql "feature"
Next
From: Andreas Karlsson
Date:
Subject: Re: bug in citext's upgrade script for parallel aggregates