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

In response to

Responses

Browse pgsql-hackers by date

  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