Re: [HACKERS] SQL procedures

On Wed, Nov 8, 2017 at 11:03 AM, Peter Eisentraut wrote: > On 11/8/17 11:11, Merlin Moncure wrote: >> On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut >> wrote: >>> I have already submitted a separate patch that addresses these

Re: [HACKERS] SQL procedures

On 11/8/17 11:11, Merlin Moncure wrote: > On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut > wrote: >> I have already submitted a separate patch that addresses these questions. > > Maybe I'm obtuse, but I'm not seeing it? In very interested in the > general

Re: [HACKERS] SQL procedures

On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut wrote: > I have already submitted a separate patch that addresses these questions. Maybe I'm obtuse, but I'm not seeing it? In very interested in the general approach to transaction management; if you've described

Re: [HACKERS] SQL procedures

On 11/8/17 09:23, Merlin Moncure wrote: > I do wonder how transaction control could be added later. > > The last time I (lightly) looked at this, I was starting to think that > working transaction control into the SPI interface was the wrong > approach; pl/pgsql would have to adopt a very

Re: [HACKERS] SQL procedures

On 11/8/17 09:33, Pavel Stehule wrote: > We can create auto session variable STATUS. This variable can be 0 > if procedure was returned without explicit RETURN value. Or it can > hold different value specified by RETURN expr. > > This value can be read by GET DIAGNOSTICS xxx =

Re: [HACKERS] SQL procedures

On 11/6/17 16:27, Simon Riggs wrote: > You mention PARALLEL SAFE is not used for procedures. Isn't it an > architectural restriction that procedures would not be able to execute > in parallel? (At least this year) I'm not sure what you are referring to here. I don't think the functionality I'm

Re: [HACKERS] SQL procedures

Peter Eisentraut writes: > On 10/31/17 14:23, Tom Lane wrote: >> Why not use VOIDOID for the prorettype value? > We need a way to distinguish functions that are callable by SELECT and > procedures that are callable by CALL. Do procedures of this ilk belong in

Re: [HACKERS] SQL procedures

On 08.11.2017 17:23, Merlin Moncure wrote: On Tue, Oct 31, 2017 at 12:23 PM, Peter Eisentraut wrote: - Transaction control in procedure bodies This feature is really key, since it enables via SQL lots of things that are not possible without external coding,

Re: [HACKERS] SQL procedures

2017-11-08 15:31 GMT+01:00 Pavel Stehule : > > > 2017-11-08 15:23 GMT+01:00 Peter Eisentraut com>: > >> On 10/31/17 16:50, Pavel Stehule wrote: >> > Not sure if disabling RETURN is good idea. I can imagine so optional >> > returning

Re: [HACKERS] SQL procedures

2017-11-08 15:23 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 10/31/17 16:50, Pavel Stehule wrote: > > Not sure if disabling RETURN is good idea. I can imagine so optional > > returning something like int status can be good idea. Cheaper than > > raising a exception. > >

Re: [HACKERS] SQL procedures

On Tue, Oct 31, 2017 at 12:23 PM, Peter Eisentraut wrote: > - Transaction control in procedure bodies This feature is really key, since it enables via SQL lots of things that are not possible without external coding, including: *) very long running processes in

Re: [HACKERS] SQL procedures

On 10/31/17 16:50, Pavel Stehule wrote: > Not sure if disabling RETURN is good idea. I can imagine so optional > returning something like int status can be good idea. Cheaper than > raising a exception. We could allow a RETURN without argument in PL/pgSQL, if you just want to exit early. That

Re: [HACKERS] SQL procedures

On 10/31/17 14:23, Tom Lane wrote: > Putting 0 in prorettype seems like a pretty bad idea. It seemed like the natural thing to do, since we use a zero OID to indicate "nothing" in many other places. > Why not use VOIDOID for the prorettype value? We need a way to distinguish functions that are

Re: [HACKERS] SQL procedures

On 31 October 2017 at 17:23, Peter Eisentraut wrote: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) Looks good >

Re: [HACKERS] SQL procedures

2017-10-31 18:23 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) > > Everything that follows

Re: [HACKERS] SQL procedures

2017-10-31 18:23 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) > > Everything that follows

Re: [HACKERS] SQL procedures

Peter Eisentraut writes: > I've been working on SQL procedures. No comment yet on the big picture here, but ... > The provided procedural languages (an ever more > confusing term) each needed a small touch-up to handle pg_proc entries > with prorettype == 0.

Re: [HACKERS] SQL procedures

On 31 October 2017 at 18:23, Peter Eisentraut wrote: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) I guess that the DO