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 3046005.1677974818@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  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Request for comment on setting binary format output per session  (Dave Cramer <davecramer@gmail.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Sat, 2023-03-04 at 18:04 -0500, Dave Cramer wrote:
>> Most of the clients know how to decode the builtin types. I'm not
>> sure there is a use case for binary encode types that the clients
>> don't have a priori knowledge of.

> The client could, in theory, have a priori knowledge of a non-builtin
> type.

I don't see what's "in theory" about that.  There seems plenty of
use for binary I/O of, say, PostGIS types.  Even for built-in types,
do we really want to encourage people to hard-wire their OIDs into
applications?

I don't see a big problem with driving this off a GUC, but I think
it should be a list of type names not OIDs.  We already have plenty
of precedent for dealing with that sort of thing; see search_path
for the canonical example.  IIRC, there's similar caching logic
for temp_tablespaces.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Request for comment on setting binary format output per session
Next
From: Tom Lane
Date:
Subject: Re: Add standard collation UNICODE