Re: default result formats setting

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
>

In response to

Browse pgsql-hackers by date

  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"?