Re: [HACKERS] SQL procedures - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] SQL procedures
Date
Msg-id CAFj8pRDz0WrBEOA02dqPQ_BOtfFbRQOQNGXrEyszW49BnGBMQQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] SQL procedures  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] SQL procedures  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers


2017-11-08 15:31 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:


2017-11-08 15:23 GMT+01:00 Peter Eisentraut <peter.eisentraut@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 could allow a RETURN without argument in PL/pgSQL, if you just want
to exit early.  That syntax is currently not available, but it should
not be hard to add.

I don't understand the point about wanting to return an int.  How would
you pass that around, since there is no declared return type?

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 = STATUS

or some similar.

The motivation is allow some mechanism cheaper than our exceptions.

Regards

Pavel



--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] SQL procedures
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager