Re: Request for comment on setting binary format output per session
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
Dave Cramer <davecramer@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-03-22T18:42:26Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Silence compiler warning introduced in 1edb3b491b
- fba2112b1569 17.0 cited
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