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

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: Request for comment on setting binary format output per session
Дата
Msg-id CADK3HH+h9OZmgDFDx=iYDd5RdFEV8iMpsgFPnsc4oCXO2EYe=w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Request for comment on setting binary format output per session  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Request for comment on setting binary format output per session
Список pgsql-hackers


On Sat, 4 Mar 2023 at 19:06, 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?

How does a client read these? I'm pretty narrowly focussed. The JDBC API doesn't really have a way to read a non built-in type.  There is a facility to read a UDT, but the user would have to provide that transcoder. I guess I'm curious how other clients read binary UDT's ?

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.

I have no issue with allowing names, OID's were compact, but we could easily support both

Dave

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Lukas Fittl
Дата:
Сообщение: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Deduplicate logicalrep_read_tuple()