Re: gset updated patch - Mailing list pgsql-hackers

From Karl O. Pinc
Subject Re: gset updated patch
Date
Msg-id 1353338239.9386.3@mofo
Whole thread Raw
In response to Re: gset updated patch  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: gset updated patch
Re: gset updated patch
List pgsql-hackers
On 11/19/2012 02:30:49 AM, Pavel Stehule wrote:
> Hello
>
> 2012/11/16 Karl O. Pinc <kop@meme.com>:
> > Hi Pavel,
> >
> > On 11/16/2012 12:21:11 AM, Pavel Stehule wrote:
> >> 2012/11/16 Karl O. Pinc <kop@meme.com>:
> >
> >> > 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.


> > You might consider using "do".
>
> it is reason, why I don't thinking about plpgsql on client side. But
> I
> don't understand how it is related to gset ?

Because the plpgsql SELECT INTO sets variables from query results,
exactly what \gset does.  You have to use EXECUTE
in plpgsql to do the substitution into statements, but that's
syntax.

>
> I remember, there is one significant limit of DO statement - it
> cannot
> return table - so it cannot substitute psql simple scripts.

Yes. I'm wrong.  For some reason I thought you could use DO to make
an anonymous code block that would act as a SETOF function,
allowing RETURN NEXT expr (et-al) to be used in the
plpgsql code, allowing DO to return table results.
(Or, perhaps, instead, be used in place of a table in a SELECT
statement.)  Oh well.

Regards,

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




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_dump --split patch
Next
From: Amit kapila
Date:
Subject: Re: [WIP PATCH] for Performance Improvement in Buffer Management