public inbox for [email protected]help / color / mirror / Atom feed
Re: Seeking Clarification on Function Definitions in PostgreSQL Extensions 5+ messages / 3 participants [nested] [flat]
* Re: Seeking Clarification on Function Definitions in PostgreSQL Extensions @ 2024-06-18 18:27 Ron Johnson <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Ron Johnson @ 2024-06-18 18:27 UTC (permalink / raw) To: pgsql-generallists.postgresql.org <[email protected]> On Tue, Jun 18, 2024 at 1:57 PM David G. Johnston < [email protected]> wrote: > On Tuesday, June 18, 2024, Ron Johnson <[email protected]> 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. > Because the out parameters and the “record” represent the exact same thing. > What's the purpose? Legacy of not having procedures? ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Seeking Clarification on Function Definitions in PostgreSQL Extensions @ 2024-06-18 18:37 David G. Johnston <[email protected]> parent: Ron Johnson <[email protected]> 0 siblings, 2 replies; 5+ messages in thread From: David G. Johnston @ 2024-06-18 18:37 UTC (permalink / raw) To: Ron Johnson <[email protected]>; +Cc: pgsql-generallists.postgresql.org <[email protected]> On Tuesday, June 18, 2024, Ron Johnson <[email protected]> wrote: > On Tue, Jun 18, 2024 at 1:57 PM David G. Johnston < > [email protected]> wrote: > >> On Tuesday, June 18, 2024, Ron Johnson <[email protected]> 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. > > >> Because the out parameters and the “record” represent the exact same >> thing. >> > > What's the purpose? Legacy of not having procedures? > So people can have a style guide that says always specify a returns clause on function definitions. David J. ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Seeking Clarification on Function Definitions in PostgreSQL Extensions @ 2024-06-18 19:04 Ron Johnson <[email protected]> parent: David G. Johnston <[email protected]> 1 sibling, 1 reply; 5+ messages in thread From: Ron Johnson @ 2024-06-18 19:04 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: pgsql-generallists.postgresql.org <[email protected]> On Tue, Jun 18, 2024 at 2:37 PM David G. Johnston < [email protected]> wrote: > On Tuesday, June 18, 2024, Ron Johnson <[email protected]> wrote: > >> On Tue, Jun 18, 2024 at 1:57 PM David G. Johnston < >> [email protected]> wrote: >> >>> On Tuesday, June 18, 2024, Ron Johnson <[email protected]> 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. ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Seeking Clarification on Function Definitions in PostgreSQL Extensions @ 2024-06-18 19:17 David G. Johnston <[email protected]> parent: Ron Johnson <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: David G. Johnston @ 2024-06-18 19:17 UTC (permalink / raw) To: Ron Johnson <[email protected]>; +Cc: pgsql-generallists.postgresql.org <[email protected]> On Tuesday, June 18, 2024, Ron Johnson <[email protected]> wrote: > On Tue, Jun 18, 2024 at 2:37 PM David G. Johnston < > [email protected]> wrote: > >> On Tuesday, June 18, 2024, Ron Johnson <[email protected]> wrote: >> >>> On Tue, Jun 18, 2024 at 1:57 PM David G. Johnston < >>> [email protected]> wrote: >>> >>>> On Tuesday, June 18, 2024, Ron Johnson <[email protected]> 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. ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Seeking Clarification on Function Definitions in PostgreSQL Extensions @ 2024-06-18 20:04 Tom Lane <[email protected]> parent: David G. Johnston <[email protected]> 1 sibling, 0 replies; 5+ messages in thread From: Tom Lane @ 2024-06-18 20:04 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Ron Johnson <[email protected]>; pgsql-generallists.postgresql.org <[email protected]> "David G. Johnston" <[email protected]> writes: > On Tuesday, June 18, 2024, Ron Johnson <[email protected]> wrote: >> What's the purpose? Legacy of not having procedures? > So people can have a style guide that says always specify a returns clause > on function definitions. To my mind, the reason we allow RETURNS together with OUT parameter(s) is so there's a place to write SETOF if you want that. Yes, the RETURNS TABLE syntax is somewhat redundant with RETURNS SETOF. Blame the SQL standard for that. regards, tom lane ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2024-06-18 20:04 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-06-18 18:27 Re: Seeking Clarification on Function Definitions in PostgreSQL Extensions Ron Johnson <[email protected]> 2024-06-18 18:37 ` David G. Johnston <[email protected]> 2024-06-18 19:04 ` Ron Johnson <[email protected]> 2024-06-18 19:17 ` David G. Johnston <[email protected]> 2024-06-18 20:04 ` Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox