Hi, On 2020-07-14 19:46:52 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > 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 :(. > > It's not a problem particularly for built-in types, but I agree > there's an issue for extension types.
I'm not so sure. That's true for builtin types within a single major version, but not necessarily across major versions. Not that I can immediately recall cases where we renumbered type oids. It also assumes that the type specification exactly matches between the source / target system. It's probably not a great idea to try to use send/recv for meaningfully different types, but it doesn't seem to crazy to e.g. allow to e.g. change varchar to text while doing a major version upgrade over logical rep. What is the gain in having these checks? recv functions need to be safe against arbitrary input, so a type crosscheck doesn't buy additional safety in that regard. Not that a potential attacker couldn't just change the content anyways? > > 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 > > Maybe we could compromise by omitting the check if both OIDs are > outside the built-in range? Hm. That'd be a lot better than the current situation. So I'd definitely go for that if that's what we can agree on. Greetings, Andres Freund
