On Tuesday, June 18, 2024, Ron Johnson <ronljohnso...@gmail.com> wrote:
> On Tue, Jun 18, 2024 at 2:37 PM David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Tuesday, June 18, 2024, Ron Johnson <ronljohnso...@gmail.com> wrote: >> >>> On Tue, Jun 18, 2024 at 1:57 PM David G. Johnston < >>> david.g.johns...@gmail.com> wrote: >>> >>>> On Tuesday, June 18, 2024, Ron Johnson <ronljohnso...@gmail.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.
