Re: Proposal: real procedures again (8.4)
От | Hannu Krosing |
---|---|
Тема | Re: Proposal: real procedures again (8.4) |
Дата | |
Msg-id | 1193695100.7351.5.camel@hannu-laptop обсуждение исходный текст |
Ответ на | Re: Proposal: real procedures again (8.4) (David Fetter <david@fetter.org>) |
Ответы |
Re: Proposal: real procedures again (8.4)
|
Список | pgsql-hackers |
Ühel kenal päeval, L, 2007-10-27 kell 14:10, kirjutas David Fetter: > On Sun, Oct 28, 2007 at 12:05:26AM +0300, Hannu Krosing wrote: > > Ühel kenal päeval, L, 2007-10-27 kell 12:55, kirjutas Josh Berkus: > > > Merlin, Pavel, > > > > > > > Mutable session variables would be nice, but I'll take a plpgsql > > > > langauge (or psm) with or without them, so long as transactions > > > > are manual. It's possible to emulate variables using scalar > > > > functions with the desired volatility currently (but you still > > > > have to be careful with transactions). > > > > > > The other big useful feature we're missing from Functions is > > > multisets. > > > > I think that support for multisets has been removed from our fe-be > > protocol implementation bit-by-bit. > > How do you mean? > > The only way I've done multisets is by creating functions that return > multiple refcursors, either in a row or as SETOF. Is or was there > some other way? I _think_ that originally an SQL function with multiple SELECTs was meant to return results for all these in a row, as a multiset. I don't think that this has ever been the case, at least not after switch from Postgres 4.2 Quel to Postgres95 SQL. What I was referring to, was a "code cleanup" of libpq several years ago, when someone (maybe Bruce IIRC) removed ability to accept multiple recordsets from backend altogether, on the basis that it is not used anyway. ---------------- Hannu
В списке pgsql-hackers по дате отправления: