Re: CALL versus procedures with output-only arguments - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: CALL versus procedures with output-only arguments
Date
Msg-id 5d0cb462-179f-9ed0-c4bc-042b997504aa@dunslane.net
Whole thread Raw
In response to Re: CALL versus procedures with output-only arguments  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 5/31/21 4:25 PM, Tom Lane wrote:
>
> Oh... just noticed something else relevant to this discussion: SR 13
> in the same section saith
>
>   13) If R is an SQL-invoked function, then no <SQL parameter declaration>
>   in NPL shall contain a <parameter mode>.
>
> In other words, the spec does not have OUT or INOUT parameters for
> functions.  So, again, their notion of what is sufficient to identify
> a routine is based on a very different model than what we are using.  
>
>             



Historical note: this might have had its origin in Ada, where it was the
rule. It's thus amusing that as of the 2012 revision Ada no longer has
this rule, and functions as well as procedures can have IN OUT and OUT
parameters (although there the return value is separate from any OUT
parameter). Ada probably dropped the rule because it was simply a
hindrance rather than a help - certainly I remember finding that it
forced somewhat unnatural expressions back when I was an Ada programmer
(mid 90s). Maybe the SQL spec needs to catch up :-)


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Greg Sabino Mullane
Date:
Subject: Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM
Next
From: Tom Lane
Date:
Subject: Re: join pushdown and issue with foreign update