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

On Mon, 20 Mar 2023 at 19:10, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

>
>
> On Mon, Mar 13, 2023 at 3:33 PM Dave Cramer <davecramer(at)gmail(dot)com> wrote:
>
>>
>> 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.
>>
>
> OIDs are a pain to deal with IMO. They will not survive a dump style
> restore, and are hard to keep synchronized between databases...type names
> don't have this problem. OIDs are an implementation artifact that ought
> not need any extra dependency.
>
AFAIK, OID's for built-in types don't change.
Clearly we need more thought on how to deal with UDT's

>
>
> This seems like a protocol or even a driver issue rather than a GUC issue.
> Why does the server need to care what format the client might want to
> prefer on a query by query basis?
>

Actually this isn't a query by query basis. The point of this is that the
client wants all the results for given OID's in binary.

> I just don't see it. The resultformat switch in libpq works pretty well,
> except that it's "all in" on getting data from the server, with the dead
> simple workaround of casting to text which might even be able to be managed
> from within the driver itself.
>
> merlin
>
>
>