From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Dave Cramer <davecramer(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
Subject: | Re: Request for comment on setting binary format output per session |
Date: | 2023-03-20 19:09:50 |
Message-ID: | 8fc96fa2ce9c354da847ab3581bb8238012b88ef.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-03-20 19:16:39 | Re: meson documentation build open issues |
Previous Message | Tom Lane | 2023-03-20 19:09:08 | Re: Request for comment on setting binary format output per session |