Re: Binary support for pgoutput plugin

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Binary support for pgoutput plugin
Дата
Msg-id 20200714195617.3zmhsei55ovnxgcs@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Binary support for pgoutput plugin  (Dave Cramer <davecramer@gmail.com>)
Ответы Re: Binary support for pgoutput plugin  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2020-07-14 14:08:53 -0400, Dave Cramer wrote:
> On Tue, 14 Jul 2020 at 12:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> > So I started looking through this seriously, and my first question
> > is why do the docs and code keep saying that "base types" are sent
> > in binary?  Why not just "data"?  Are there any cases where we
> > don't use binary format, if the subscription requests it?
> >
> > If there's not a concrete reason to use that terminology,
> > I'd rather flush it, because it seems confusing.
> >
> 
> Well for some reason I thought there were some types that did not have send
> and receive functions.

There's also send/receive functions that do not work across systems,
unfortunately :(. In particular record and array send functions embed
type oids and their receive functions verify that they match the local
system. Which basically means that if there's any difference in oid
assignment order between two systems that they will not allow to
send/recv such data between them :(.


I suspect that is what that comments might have been referring to?


I've several times suggested that we should remove those type checks in
recv, as they afaict don't provide any actual value. But unfortunately
there hasn't been much response to that. See e.g.

https://postgr.es/m/20160426001713.hbqdiwvf4mkzkg55%40alap3.anarazel.de

Greetings,

Andres Freund



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: recovering from "found xmin ... from before relfrozenxid ..."
Следующее
От: Robert Haas
Дата:
Сообщение: Re: recovering from "found xmin ... from before relfrozenxid ..."