Re: [HACKERS] SQL procedures

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: [HACKERS] SQL procedures
Date: 2017-11-22 19:18:26
Message-ID: 7ac4688b-c210-1baa-3586-b37df3075fec@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/22/2017 01:10 PM, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashwin Agrawal 2017-11-22 19:32:56 Re: [HACKERS] Commits don't block for synchronous replication
Previous Message Peter Eisentraut 2017-11-22 19:08:28 Re: Allowing SSL connection of v11 client to v10 server with SCRAM channel binding