On Tue, 4 Jun 2019 at 16:46, Andres Freund <and...@anarazel.de> wrote:
> Hi, > > On 2019-06-04 16:39:32 -0400, Dave Cramer wrote: > > On Tue, 4 Jun 2019 at 16:30, Andres Freund < > andres.fre...@enterprisedb.com> > > wrote: > > > > There's also no reason that I am aware that binary outputs can't be > > > > supported. > > > > > > Well, it *does* increase version dependencies, and does make > replication > > > more complicated, because type oids etc cannot be relied to be the same > > > on source and target side. > > > > > I was about to agree with this but if the type oids change from source > > to target you still can't decode the text version properly. Unless I > > mis-understand something here ? > > The text format doesn't care about oids. I don't see how it'd be a > problem? Note that some people *intentionally* use different types from > source to target system when logically replicating. So you can't rely on > the target table's types under any circumstance. > > I think you really have to use the textual type which we already write > out (cf logicalrep_write_typ()) to call the binary input functions. And > you can send only data as binary that's from builtin types - otherwise > there's no guarantee at all that the target system has something > compatible. And even if you just assumed that all extensions etc are > present, you can't transport arrays / composite types in binary: For > hard to discern reasons we a) embed type oids in them b) verify them. b) > won't ever work for non-builtin types, because oids are assigned > dynamically. > I figured arrays and UDT's would be problematic. > > > > > I think if we were to add binary output - and I think we should - we > > > ought to only accept a patch if it's also used in core. > > > > > > > Certainly; as not doing so would make my work completely irrelevant for > my > > purpose. > > What I mean is that the builtin logical replication would have to use > this on the receiving side too. > > Got it, thanks for validating that the idea isn't nuts. Now I *have* to produce a POC. Thanks, Dave > >
