Re: unexpected psql "feature"

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: unexpected psql "feature"
Дата
Msg-id 6255.1468451554@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: unexpected psql "feature"  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: unexpected psql "feature"  (Geoff Winkless <pgsqladmin@geoff.dj>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: unexpected psql "feature"
Следующее
От: Andreas Karlsson
Дата:
Сообщение: Re: bug in citext's upgrade script for parallel aggregates