On Tue, Jun 04, 2019 at 04:55:33PM -0400, Dave Cramer wrote: > 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.
Would it make sense to work toward a binary format that's not architecture-specific? I recall from COPY that our binary format is not standardized across, for example, big- and little-endian machines. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
