Re: Request for comment on setting binary format output per session
От | David G. Johnston |
---|---|
Тема | Re: Request for comment on setting binary format output per session |
Дата | |
Msg-id | CAKFQuwYAxv4+YkzmiAckLLan5-QNpvR70Mu4GWZgSQz4_n=F6Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Request for comment on setting binary format output per session (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, Mar 4, 2023 at 5:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jeff Davis <pgsql@j-davis.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.
В списке pgsql-hackers по дате отправления: