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 1sKgCq-00Ba6C-LI for pgsql-general@arkaria.postgresql.org; Fri, 21 Jun 2024 15:29:40 +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 1sKgCo-003InJ-6T for pgsql-general@arkaria.postgresql.org; Fri, 21 Jun 2024 15:29:38 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sKgCn-003ImC-Q5 for pgsql-general@lists.postgresql.org; Fri, 21 Jun 2024 15:29:38 +0000 Received: from mail-oi1-x233.google.com ([2607:f8b0:4864:20::233]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sKgCm-002qab-3w for pgsql-general@lists.postgresql.org; Fri, 21 Jun 2024 15:29:37 +0000 Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3d21e00d9cfso1231418b6e.2 for ; Fri, 21 Jun 2024 08:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718983774; x=1719588574; 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=vEQSfBs+N390xadAy0lBkOT8jhnitZN4BYMQ6GaXq1w=; b=ay61piGr+zqFNucgHcwkD9UFBxkXEXRFi60MrzpdXsEu8d258B3AlGM3GrGI3thKEF 3XmcTqpv2w9sr5DTcpPQM0KSWgrmMFmhpLu6Vb8WacNKEk/R0OxLRY9PsJjzUrvY+lbA +tVRxBykLblQxz4iz0l29mdV15g4oOCiLDADeUzlZ7Tsl4UOpjJAQ30DPs0OHSqaZF8b pSET+oValTALt5oiZQvacz0RN/WLjezATIPOOBwcvNpdZR67qUCmkAJLK6DEzy8WDU8v y2uMddmk9L9/l1e8HZjsgxEGdr42dpQ0OJ6Rp8/VAhJ05JBs9Ny4x5cSiyEzR2sWW8YF DCXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718983774; x=1719588574; 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=vEQSfBs+N390xadAy0lBkOT8jhnitZN4BYMQ6GaXq1w=; b=jAFzue9ouhybO9MpxA8GMkLaCFaQyyJBnPRy187zxnXTRTVjLEJP8Wc7wJoAxTMldm rGztIai5enMqBpmF5rgfgysnLDOiJWJI72WgsTWLSODNDhbrp4alD90iWiNKA5leZ9AW g/v2xfPazmaoui6rYB0PNJjQLvkINBr/IBCuRh6OjSA7AZwMK3dlZQm/kotg8Y9v3ZiM RBP13YJKV94CDnoUoX+eGFYmsGBKI/fmq+TbkqhtBOMuLqC9K/0lgAIA+LuhsKQeBHk0 3wQhnU/SpMLeDPYqscsH5UnOv4CPLqycf8SsqKEl+zJb7/vZe1nGrNmQYzDvvIFPG6Z6 kzfw== X-Gm-Message-State: AOJu0YwSMAGnpHUiEJpXdDSpn3iwAJeIdiArnBpEEUGWmogEK8okVFXQ FoT3cSdjOqUFeAiKqVUGAeJ6DRXRdZjsmtVGpP9PNay1aoCsH0fCU4IcBg+MR5FdXuDfXO6jtcW Aj9FXI631BucJtGLQrf9xbF7GOuoLebnt X-Google-Smtp-Source: AGHT+IHJfmQLJ3cgJL4YZyj/eZBtGLTmNIsf3ckAD74/SHbxrCDRtLO4Rj4fmDmeP1LmpxKpkjhvi2I5Nm7T9Azlsrc= X-Received: by 2002:a05:6871:3b2b:b0:254:bf41:de9d with SMTP id 586e51a60fabf-25c94d713e3mr6667659fac.48.1718983773576; Fri, 21 Jun 2024 08:29:33 -0700 (PDT) MIME-Version: 1.0 References: <3528232.1718682678@sss.pgh.pa.us> In-Reply-To: From: "David G. Johnston" Date: Fri, 21 Jun 2024 08:28:56 -0700 Message-ID: Subject: Re: RowDescription for a function does not include table OID To: Maxwell Dreytser Cc: "pgsql-general@lists.postgresql.org" Content-Type: multipart/alternative; boundary="00000000000032e6f5061b681993" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000032e6f5061b681993 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2024 at 8:04=E2=80=AFAM Maxwell Dreytser < Maxwell.Dreytser@assistek.com> wrote: > On Friday, June 21, 2024 10:48 AM David G. Johnston < > david.g.johnston@gmail.com>wrote: > > >Yes, but the bug is yours. The definition you want is: RETURNS SETOF > physical_table (not tested though) > >What you did was produce a one-column table whose column type is a > composite (and whose name is like - what with case-folding of unquoted > identifiers). Since that table doesn't exist anywhere in the catalogs it > has no TableOID. > > SETOF also does not return correct RowDescription data. Table OID and > column number are still both 0. > Both versions have the exact same pg_proc.prorettype. If I join this onto > pg_type, the pg_type.typrelid =3D 'physical_table'::regclass. > > Interesting, then I suppose it is semantics. There is no table involved - you are referencing the type of that name, not the table - so no TableOID. There is no guarantee the row you are holding came from a table - and I'd interpret the current behavior as conveying that fact. Though the current wording: "If the field can be identified as a column of a specific table, the object ID of the table; otherwise zero."; and the observation that at least a human "can identify" a related column, leads one to reasonably infer the system should be able to make such an identification as well. I would expect you'd be able to find the pg_type.oid value somewhere in the RowDescription given those specifications, but not the pg_type.typrelid value. But since the header has no allowance for a row type oid this information does seem to be missing. In short, the system doesn't generate the information you need, where you need it, to tie these pieces together. Modifying existing elements of the backend protocol is not presently in the cards. David J. --00000000000032e6f5061b681993 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 21, 2024 at 8:04=E2=80=AFAM Maxwell Dreytser &= lt;Maxwell.Dreytser@assist= ek.com> wrote:
On=C2=A0Friday, June 21, 2024= 10:48 AM=C2=A0David G. Johnston <david.g.johnston@gmail.com>wrote:

>Yes, but the bug is yours.=C2=A0 The definition you want is:=C2=A0 RETU= RNS SETOF physical_table (not tested though)
>What you did was produce a one-column table whose column type is a comp= osite (and whose name is like - what with case-folding of unquoted identifi= ers).=C2=A0 Since that table doesn't exist anywhere in the catalogs it = has no TableOID.

SETOF also does not return correct RowDescription data. Table OID and colum= n number are still both 0.
Both versions have the exact same pg_proc.prorettype. If I join this onto p= g_type, the pg_type.typrelid =3D 'physical_table'::regclass.

Interesting, then I suppose it is semantics= .=C2=A0 There is no table involved - you are referencing the type of that n= ame, not the table - so no TableOID.=C2=A0 There is no guarantee the row yo= u are holding came from a table - and I'd interpret the current behavio= r as conveying that fact.=C2=A0 Though the current wording: "If the fi= eld can be identified as a column of a specific table, the object ID of the= table; otherwise zero."; and the observation that at least a human &q= uot;can identify" a related column, leads one to reasonably infer the = system should be able to make such an identification as well.

<= /div>
I would expect you'd be able to find the pg_type.oid value some= where in the RowDescription given those specifications, but not the pg_type= .typrelid value.=C2=A0 But since the header has no allowance for a row type= oid this information does seem to be missing.

In shor= t, the system doesn't generate the information you need, where you need= it, to tie these pieces together.=C2=A0 Modifying existing elements of the= backend protocol is not presently in the cards.

David= J.

--00000000000032e6f5061b681993--