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-19 15:17:19 |
Message-ID: | 1353338239.9386.3@mofo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/19/2012 02:30:49 AM, Pavel Stehule wrote:
> Hello
>
> 2012/11/16 Karl O. Pinc <kop(at)meme(dot)com>:
> > Hi Pavel,
> >
> > On 11/16/2012 12:21:11 AM, Pavel Stehule wrote:
> >> 2012/11/16 Karl O. Pinc <kop(at)meme(dot)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(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
From | Date | Subject | |
---|---|---|---|
Next Message | Amit kapila | 2012-11-19 15:22:59 | Re: [WIP PATCH] for Performance Improvement in Buffer Management |
Previous Message | Andrew Dunstan | 2012-11-19 15:16:39 | Re: pg_dump --split patch |