| 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: | Whole Thread | Raw Message | 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 |