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.
>
> 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.
> >
> > 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?
>
> 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.
Regards,
Jeff Davis
