public inbox for [email protected]  

help / color / mirror / Atom feed

From: Maxwell Dreytser <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: RowDescription for a function does not include table OID
Date: Tue, 18 Jun 2024 04:28:34 +0000
Message-ID: <LV3PR16MB6001CD31C5982777BA9BA25EE6CE2@LV3PR16MB6001.namprd16.prod.outlook.com> (raw)
In-Reply-To: <[email protected]>
References: <LV3PR16MB6001AF4D05893E9FF4B3C746E6CE2@LV3PR16MB6001.namprd16.prod.outlook.com>
	<[email protected]>

From: Tom Lane <[email protected]>:

>Hmm, I do not think that syntax means what you think it means ;-).

Its an interesting trick that I came across on DBA SE on a question named "How to use RETURNS TABLE with an existing table in PostgreSQL?".

>However, it seems to end up with prorettype =
>physical_table'::regtype anyway thanks to some special rules about
>single-column output tables, so as far as I can see you should get
>the table's composite type OID as the column type OID in the result
>descriptor for "SELECT my_function(...)".  Or is that not the case
>you're concerned about?

The query I am running is "SELECT * FROM my_function()". According to Wireshark I can see that the returned RowDescription shows 0 for Table OID and Column index:

PostgreSQL
    Type: Row description
    Length: 219
    Field count: 7
        Column name: table_id
            Table OID: 0
            Column index: 0
            Type OID: 20
            Column length: 8
            Type modifier: -1
            Format: Binary (1)
<snipped>

>I'm confused about exactly what you're asking for, but (a) returning a
>type OID where a relation OID is expected is absolutely not OK ---
>there is no guarantee that those OID sets are distinct; (b) regardless
>of that, you seem to be asking for a silent semantic change in the
>wire protocol, which is going to be a very hard sell because it will
>probably break more applications than it makes happy.  Why can't you
>get what you need from the composite type OID?

I would indeed like the relation OID to be returned for the composite type that is returned from the function. Maybe this can be simply considered a bug as it does seem like returning the relation OID that is clearly available would be the expected behaviour.

Regards,
Maxwell.

view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: RowDescription for a function does not include table OID
  In-Reply-To: <LV3PR16MB6001CD31C5982777BA9BA25EE6CE2@LV3PR16MB6001.namprd16.prod.outlook.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox