Re: Seeking Clarification on Function Definitions in PostgreSQL Extensions

On Tuesday, June 18, 2024, Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:

> On Tue, Jun 18, 2024 at 2:37 PM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Tuesday, June 18, 2024, Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:
>>
>>> On Tue, Jun 18, 2024 at 1:57 PM David G. Johnston <
>>> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>>>
>>>> On Tuesday, June 18, 2024, Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:
>>>>
>>>>>
>>>>> But I stand by returning OUT params and records at the same time.
>>>>>
>>>>
>>>> You mean you dislike adding the optional returns clause when output
>>>> parameters exist?
>>>>
>>>
>>> Correct. It breaks the distinction between function and procedure.
>>>
>>
>> How so?
>>
>> The two distinctions are functions can produce sets while procedures get
>> transaction control.
>>
>> They both can produce a single multi-column output record. The presence
>> or absence of the optional return clause on a function definition doesn’t
>> change that fact.
>>
>
> "A function returns a value*, but a procedure does not."
>
> *In the case of SQL, "value" might be a set.
>
>
Notably it’s the use of output arguments in create function that violate
the consistency, but using them is the only way to define an adhoc
multi-column result.

I’ll accept the narrow definition of “return value” being something that be
incorporated into an expression. Procedures do not have that. Hence they
don;y have a return clause. Since the output arguments for a function are
return values specifying “returns record” just makes is perfectly clear
what is happening and that it is different than a procedure with the same
output arguments.

David J.