2012/11/19 Karl O. Pinc <k...@meme.com>: > On 11/19/2012 02:30:49 AM, Pavel Stehule wrote: >> Hello >> >> 2012/11/16 Karl O. Pinc <k...@meme.com>: >> > Hi Pavel, >> > >> > On 11/16/2012 12:21:11 AM, Pavel Stehule wrote: >> >> 2012/11/16 Karl O. Pinc <k...@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.
yes, but I cannot set a psql variable but a original proposal for gset was \exec .... into var :) although \gset is more simply and there are no problem with multiline queries > >> >> 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. yes, I understand - "batch" model for DO is more natural, than function - but it is not true :(. I hope, so one time we will have a real stored procedures with unbound queries. Then we can redefine DO behave, because it doesn't break compatibility. But it is long way - maybe 9.5 Regards Pavel > > Regards, > > Karl <k...@meme.com> > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers