Re: CALL versus procedures with output-only arguments

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: CALL versus procedures with output-only arguments
Date: 2021-06-01 19:37:47
Message-ID: 5d0cb462-179f-9ed0-c4bc-042b997504aa@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-06-01 20:01:34 Re: join pushdown and issue with foreign update
Previous Message Greg Sabino Mullane 2021-06-01 19:25:18 Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM