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 questions.
>>
>> Maybe I'm obtuse, but I'm not seeing it? In very int
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 approach to transaction management; if
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 it in
the patch I'll read it there
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 differen
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 = STAT
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 pr
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 pg_proc at all? It seems like a lar
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, including:
*) very long running pr
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 something like int status can be good idea. Cheaper than
>> > ra
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.
>
> We
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 a single routine
*) transaction iso
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 syn
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 c
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
> Everything that follows is intended to alig
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 is
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 is
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.
Putting 0 in prorettype seems like a
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 command might have a variant to allo
18 matches
Mail list logo
