Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sJe89-00628y-H1 for pgsql-general@arkaria.postgresql.org; Tue, 18 Jun 2024 19:04:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sJe87-0016cs-9Z for pgsql-general@arkaria.postgresql.org; Tue, 18 Jun 2024 19:04:32 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sJe86-0016cj-V5 for pgsql-general@lists.postgresql.org; Tue, 18 Jun 2024 19:04:31 +0000 Received: from mail-oa1-x29.google.com ([2001:4860:4864:20::29]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sJe85-001xct-EF for pgsql-general@lists.postgresql.org; Tue, 18 Jun 2024 19:04:30 +0000 Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-254e42df409so3628243fac.0 for ; Tue, 18 Jun 2024 12:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718737468; x=1719342268; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dy5h8BNUD8DANnVMU8NrPby7stTnUQsRMrebbTJ/YiY=; b=HO0VQLD4uIUsL+MvPmMfnFUZ+pjzE+5dG2FIkgQ3nMLDsCq6LmKBluXhf0yNg4qPhH Zu9yZ+WMI9Lz+bIqqk0Si16kIJnMPvw4iZdO1o0giTNjPxiZWn8640/6vVwkjPzej72B MojAW23vXCRGioJPlh1bOeJFff3J+5fyt2HtQ53bGuW1cGj5R5bTf12TBegBuxUBx+RA x0ivsy4ucJaoB9+texvM3SuVfUJ3vyYrcFAJrcR/pl+otXGfJG1qI51DN0CtNXSIYWUS 3NvqbWIWUNlTVVI16/vJEqe4udYA+/MvB4HnjX6t5dupNvFURhUpb8SfW621KE+/0t9/ 9nrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718737468; x=1719342268; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dy5h8BNUD8DANnVMU8NrPby7stTnUQsRMrebbTJ/YiY=; b=MAqkWAidIb0v6M04KB0c9P7IHE8nz2gvifPnnqsAOu0ft3gKCjTCH88aR4BGSge5a3 KZko5MsX0K74eBIheCYu/f8m2zF1vlwDEgvAG5SK/xAoNp2m+dXG4kCWbExJ/YutUvFE +w1yPmnoTSY9BXJCyf1hACICE8bo1JU+1FYp6u1c2wjcgDhyt/DeTyYq7C7RUJ15C0fm XgPyeSefrgUio4w+INIzlMOwwo0La0CqoG4XVjrpdYdZ1baG0lu50W3QwqNLwdzDparJ 9zrtY4Y3Q2esHYh/kGw9aIaYn+oiZnmdTaGoQXxa5oUbWCf9MHFbiMK6ojiotrS70FE0 qkBQ== X-Gm-Message-State: AOJu0Yyw+hAoYsxpD3gA8QFT3KxAX18Z3sBDCSQre6xq4Ja/yJyVsRgL ONztX1yv0DhWBXdW/weA9Pxb4QkayBM8wlRP1yQLIoSHmCrZnCg9n2CIPKRPhb0xrsIbqbtSEgI +BNejisxgqSgesy+n6rS+Ya2Aklk= X-Google-Smtp-Source: AGHT+IGbOe6flFctLeCOJs/LHZqD4WBF+UMUsCLeLyG+kPPwVf7DJ3g2cBnEo2bu0+ONCY7Jdzlfy1KlutE1cR6eCik= X-Received: by 2002:a05:6870:2214:b0:254:b5b9:3552 with SMTP id 586e51a60fabf-25c94abd51bmr717780fac.33.1718737468563; Tue, 18 Jun 2024 12:04:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Tue, 18 Jun 2024 15:04:17 -0400 Message-ID: Subject: Re: Seeking Clarification on Function Definitions in PostgreSQL Extensions To: "David G. Johnston" Cc: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="00000000000046aaf6061b2ec0d3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000046aaf6061b2ec0d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 18, 2024 at 2:37=E2=80=AFPM David G. Johnston < david.g.johnston@gmail.com> wrote: > On Tuesday, June 18, 2024, Ron Johnson wrote: > >> On Tue, Jun 18, 2024 at 1:57=E2=80=AFPM David G. Johnston < >> david.g.johnston@gmail.com> wrote: >> >>> On Tuesday, June 18, 2024, Ron Johnson 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= =E2=80=99t > change that fact. > "A function returns a value*, but a procedure does not." *In the case of SQL, "value" might be a set. --00000000000046aaf6061b2ec0d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 18, 2024 at 2:37=E2=80=AFPM D= avid G. Johnston <david.g.= johnston@gmail.com> wrote:
On Tuesday, June 18, 2024, Ron= Johnson <r= onljohnsonjr@gmail.com> wrote:
On Tue, Jun 18, 2024 at 1= :57=E2=80=AFPM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Tuesday, June 18, 2024, Ron Johnson <ronljohnsonjr@gmail.com> wrote:
=

But I stand by returning= OUT params and records at the same=C2=A0time.

You mean you dislike adding the optional returns clau= se when output parameters exist?=C2=A0

Correct.=C2=A0 It breaks the distinction between function and procedure.=

How so?

The two distinctions are functions can produce sets while procedur= es get transaction control.

They both can produce = a single multi-column output record.=C2=A0 The presence or absence of the o= ptional return clause on a function definition doesn=E2=80=99t change that = fact.

"A function returns a valu= e*, but a procedure does not."

*In the ca= se of SQL, "value" might be a set.

--00000000000046aaf6061b2ec0d3--