From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Dave Cramer <davecramer(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Request for comment on setting binary format output per session |
Date: | 2023-03-05 00:13:13 |
Message-ID: | CAKFQuwYAxv4+YkzmiAckLLan5-QNpvR70Mu4GWZgSQz4_n=F6Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 4, 2023 at 5:07 PM 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?
>
> 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.
>
>
This seems slightly different since types depend upon schemas whereas
search_path is top-level and tablespaces are global. But I agree that
names should be accepted, maybe in addition to OIDs, the latter, for core
types in particular, being a way to not have to worry about masking in
user-space.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Lukas Fittl | 2023-03-05 00:20:59 | Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment |
Previous Message | Tom Lane | 2023-03-05 00:10:36 | Re: Add standard collation UNICODE |