From: | "Karl O(dot) Pinc" <kop(at)meme(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: gset updated patch |
Date: | 2012-11-16 05:08:06 |
Message-ID: | 1353042486.27898.3@mofo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-11-16 05:28:40 | Re: [WIP] pg_ping utility |
Previous Message | Tom Lane | 2012-11-16 04:55:36 | Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY |