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