Re: Request for comment on setting binary format output per session - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Request for comment on setting binary format output per session
Date
Msg-id 1645577.1679510546@sss.pgh.pa.us
Whole thread Raw
In response to Re: Request for comment on setting binary format output per session  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Request for comment on setting binary format output per session  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Wed, 2023-03-22 at 10:21 +0100, Peter Eisentraut wrote:
>> I've been thinking that we need some new kind of identifier to allow 
>> clients to process types in more sophisticated ways.
>> For example, each type could be (self-)assigned a UUID, which is fixed 
>> for that type no matter in which schema or under what extension name or 
>> with what OID it is installed.  Client libraries could then hardcode 
>> that UUID for processing the types.  Conversely, the UUID could be 
>> changed if the wire format of the type is changed, without having to 
>> change the type name.

> That sounds reasonable to me. It could also be useful for other
> extension objects (or the extension itself) to avoid other kinds of
> weirdness from name collisions or major version updates or extensions
> that depend on other extensions.

This isn't going to help much unless we change the wire protocol
so that RowDescription messages carry these UUIDs instead of
(or in addition to?) the OIDs of the column datatypes.  While
that's not completely out of the question, it's a heavy lift
that will affect multiple layers of client code along with the
server.

Also, what about container types?  I doubt it's sane for
array-of-foo to have a UUID that's unrelated to the one for foo.
Composites and ranges would need some intelligence too if we
don't want them to be unduly complicated to process.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Set arbitrary GUC options during initdb
Next
From: Melanie Plageman
Date:
Subject: Re: Remove nonmeaningful prefixes in PgStat_* fields