Re: Request for comment on setting binary format output per session

Dave Cramer

On Sat, 4 Mar 2023 at 19:39, Dave Cramer <davecramer(at)gmail(dot)com> wrote:

>
>
> On Sat, 4 Mar 2023 at 19:06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Jeff Davis <pgsql(at)j-davis(dot)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?
>>
>
> How does a client read these? I'm pretty narrowly focussed. The JDBC API
> doesn't really have a way to read a non built-in type. There is a facility
> to read a UDT, but the user would have to provide that transcoder. I guess
> I'm curious how other clients read binary UDT's ?
>
>>
>> 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.
>>
>
> I have no issue with allowing names, OID's were compact, but we could
> easily support both
>

Attached is a preliminary patch that takes a list of OID's. I'd like to
know if this is going in the right direction.

Next step would be to deal with type names as opposed to OID's.
This will be a bit more challenging as type names are schema specific.

Dave

>