Re: gset updated patch

Поиск
Список
Период
Сортировка
От Karl O. Pinc
Тема Re: gset updated patch
Дата
Msg-id 1353042486.27898.3@mofo
обсуждение исходный текст
Ответ на gset updated patch  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: gset updated patch  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On 11/03/2012 01:45:36 PM, Pavel Stehule wrote:
> Hello
>
> here is a updated patch

This message does not appear to be threaded so I'm not
sure I've read the whole back-history.  Also, I don't
really know what I'm doing.  Never the less, I want
to try to contribute to somebody else's patch so
here's my comments.  Make of them what you will.

I know there's been criticism for touching too many
different parts of the code, but writing your own
mini-lexical analyzer does not make sense to me.
There ought to be a clean way to move that into psqlscan.l
and let lex do it's job.

Since the result of a \gset is undefined if the query
fails it makes me nervous that psql would
continue running after \gset failure in a
non-interactive environment.  Perhaps \gset/psql
should distinguish between interactive and
non-interactive environments in the same way
shell does?  Do you have any use-cases where it
makes sense to continue after error in a
non-interactive environment?

As long as I'm talking crazy talk, why not
abandon psql as a shell language and instead make a
pl/pgsql interpreter with readlne() in front
of it?   Solve all these language-related
issues by using an actual programming language.  :-)

I hope at least some of the above is helpful
and I'm not just injecting noise into the system.

Regards,

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."                -- Robert A. Heinlein




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [WIP] pg_ping utility