Re: gset updated patch

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

In response to

Responses

Browse pgsql-hackers by date

  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