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

On Mon, Mar 20, 2023 at 7:11 PM Dave Cramer <davecramer(at)gmail(dot)com> wrote:

>
>
>
> 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:
>>
>>>
>>> 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
>

Yeah. Not having a solution that handles arrays and composites though
would feel pretty incomplete since they would be the one of the main
beneficiaries from a performance standpoint. I guess minimally you'd
need to expose some mechanic to look up oids, but being able to
specify "foo"."bar", in the GUC would be pretty nice (albeit a lot more
work).

> 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.
>

Yep. Your rationale is starting to click. How would this interact with
existing code bases? I get that JDBC is the main target, but how does this
interact with libpq code that explicitly sets resultformat? Perhaps the
answer should be as it shouldn't change documented behavior, and a
hypothetical resultformat=2 could be reserved to default to text but allow
for server control, and 3 as the same but default to binary.

merlin