Re: gset updated patch

Hello

2012/11/16 Karl O. Pinc <kop@meme.com>:
> 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.

it is about 20 rows only, so it is not critical and for me is not
important where parser is

>
> 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?

No, I have not a use case for continuing after error - but any
continue after error is risk - so it is similar like any other code -
it is same risk as broken output for \g statement forwarded to file
and processed later.

It can be mentioned in documentation - so preferred usage of this
command is in stop error mode

>
> 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 though about it more time, but I don't thinking so this has a sense.
Actually we cannot do perfect autocomplete for significantly simpler
SQL and there are lot of client side interprets - is not reason for
next one. I use psql together bash and it works well. But just very
simple task as storing some volatile data for repetitive usage is
relative laborious and it is a motivation for this patch. In psql I
can simply work with any fields of returned record - what is more
terrible work outside psql

Regards

Pavel Stehuke

> 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
>