On Mon, 2023-03-20 at 14:36 -0400, Dave Cramer wrote: > Thanks for the review. I'm curious what system you are running on as > I don't see any of these errors.
Are asserts enabled?
> Well I'm guessing psql doesn't know how to read date or timestamptz > in binary. This is not a failing of the code.
It seems strange, and potentially dangerous, to send binary data to a client that's not expecting it. It feels too easy to cause confusion by changing the GUC mid-session.
Also, it seems like DISCARD ALL is not resetting it, which I think is a bug.
Thanks yes, this is a bug
> > This is an interesting question. If the type isn't visible then it's > not visible to the query so
I don't think that's true -- the type could be in a different schema from the table.
Good point. This seems to be the very difficult part.
> > > > 5. There's a theoretical invalidation problem. It might also be a > > practical problem in some testing setups with long-lived > > connections > > that are recreating user-defined types. > > > > UDT's seem to be a problem here which candidly have very little use > case for binary output.
I mostly agree with that, but it also might not be hard to support UDTs. Is there a design problem here or is it "just a matter of code"?
> > I didn't try to solve it as Tom was OK with using a GUC. Using a > startup GUC is interesting, > but how would that work with pools where we want to reset the > connection when we return it and then > set the binary format on borrow ? By using a GUC when a client > borrows a connection from a pool the client > can reconfigure the oids it wants formatted in binary.
That's a good point. How common is it to share a connection pool between different clients (some of which might support a binary format, and others which don't)? And would the connection pool put connections with and without the property in different pools?
For JAVA pools it's probably OK, but for pools like pgbouncer we have no control of who is going to get the connection next.
> > I really hadn't considered supporting type names. I have asked Paul > Ramsey about PostGIS and he doesn't see PostGIS using this.
One of the things I like about Postgres is that the features all work together, and that user-defined objects are generally as good as built- in ones. Sometimes there's a reason to make a special case (e.g. syntax support or something), but in this case it seems like we could support user-defined types just fine, right? It's also just more friendly and readable to use type names, especially if it's a GUC.
