From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: default result formats setting |
Date: | 2020-11-06 05:36:18 |
Message-ID: | CAFj8pRD13fbUoqUxGGFxvgpTTWrQOv+gGqxLVHRSO-kp4oRo9w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
čt 5. 11. 2020 v 21:48 odesílatel Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> napsal:
> On 2020-10-26 09:45, Pavel Stehule wrote:
> > The attached patch implements this. For example, to get int2, int4,
> > int8 in binary by default, you could set
> >
> > SET default_result_formats = '21=1,23=1,20=1';
> >
> >
> > Using SET statement for this case looks very obscure :/
> >
> > This is a protocol related issue, and should be solved by protocol
> > extending. I don't think so SQL level is good for that.
>
> We could also make it a protocol message, but it would essentially
> implement the same thing, just again separately. And then you'd have no
> support to inspect the current setting, test out different settings
> interactively, etc. That seems pretty wasteful and complicated for no
> real gain.
>
If you need a debug API, then it can be better implemented with functions.
But why do you need it on SQL level?
This is a protocol related thing.
> > More, this format is not practical for custom types, and the list can
> > be pretty long.
>
> The list is what the list is. I don't see how you can make it any
> shorter. You have to list the data types that you're interested in
> somehow. Any other ideas?
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2020-11-06 05:40:04 | Re: [Patch] Optimize dropping of relation buffers using dlist |
Previous Message | Pavel Stehule | 2020-11-06 05:25:26 | Re: Why does to_json take "anyelement" rather than "any"? |