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

From Andrew Dunstan
Subject Re: [HACKERS] SQL procedures
Date
Msg-id 7ac4688b-c210-1baa-3586-b37df3075fec@2ndQuadrant.com
Whole thread Raw
In response to Re: [HACKERS] SQL procedures  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 11/22/2017 01:10 PM, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> On 11/20/17 16:25, Andrew Dunstan wrote:
>>> We should document where returned values in PL procedures are ignored
>>> (plperl, pltcl) and where they are not (plpython, plpgsql). Maybe we
>>> should think about possibly being more consistent here, too.
>> Yeah, suggestions?  I think it makes sense in PL/pgSQL and PL/Python to
>> disallow return values that would end up being ignored, because the only
>> way a return value could arise is if user code explicit calls
>> RETURN/return.  However, in Perl, the return value is the result of the
>> last statement, so prohibiting a return value would be very
>> inconvenient.  (Don't know about Tcl.)  So maybe the current behavior
>> makes sense.  Documentation is surely needed.
> Tcl has the same approach as Perl: the return value of a proc is the
> same as the value of its last command.  There's no such thing as a
> proc that doesn't return a value.
>
>             


Right. We probably just need to document the behaviour here. I'd be
satisfied with that.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Allowing SSL connection of v11 client to v10 server with SCRAMchannel binding
Next
From: Ashwin Agrawal
Date:
Subject: Re: [HACKERS] Commits don't block for synchronous replication