Re: Binary support for pgoutput plugin
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dave Cramer <davecramer@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Petr Jelinek <petr@2ndquadrant.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Michael Paquier <michael@paquier.xyz>,
Dmitry Dolgov <9erthalion6@gmail.com>,
Thomas Munro <thomas.munro@gmail.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Petr Jelinek <petr.jelinek@2ndquadrant.com>,
Andres Freund <andres@anarazel.de>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-07-14T18:36:37Z
Lists: pgsql-hackers
Dave Cramer <davecramer@gmail.com> writes: > 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? > Well for some reason I thought there were some types that did not have send > and receive functions. There are, but they're all base types, so this terminology is still unhelpful ;-). It'd be possible for the sender to send binary for columns it has a typsend function for, and otherwise send text. However, this only helps if the receiver has receive functions for all those types; in cross-version cases they might disagree about which types can be sent in binary. (Hm ... maybe we could have the receiver verify that it has typreceive for every column included in its version of the table, before asking for binary mode?) regards, tom lane
Commits
-
Weaken type-OID-matching checks in array_recv and record_recv.
- 670c0a1d474b 14.0 landed
-
Fix construction of updated-columns bitmap in logical replication.
- e8de627a3e05 11.9 landed
- d5daae47db5e 14.0 landed
- 71e561bd4bc2 12.4 landed
- 39d6aec1927c 10.14 landed
- 2f1f189cf880 13.0 landed
-
Allow logical replication to transfer data in binary format.
- 9de77b545313 14.0 landed
-
Phase 2 pgindent run for v12.
- 8255c7a5eeba 12.0 cited