+Paul Ramsey On Mon, 20 Mar 2023 at 13:05, Jeff Davis <pg...@j-davis.com> wrote:
> On Mon, 2023-03-13 at 16:33 -0400, Dave Cramer wrote: > > Attached is a preliminary patch that takes a list of OID's. I'd like > > to know if this is going in the right direction. > > Thanks for the review. I'm curious what system you are running on as I don't see any of these errors. > I found a few issues: > > 1. Some kind of memory error: > > SET format_binary='25,1082,1184'; > WARNING: problem in alloc set PortalContext: detected write past > chunk end in block 0x55ba7b5f7610, chunk 0x55ba7b5f7a48 > ... > SET > 2. Easy to confuse psql: > > CREATE TABLE a(d date, t timestamptz); > SET format_binary='25,1082,1184'; > SELECT * FROM a; > d | t > ---+--- > ! | > (1 row) > > Well I'm guessing psql doesn't know how to read date or timestamptz in binary. This is not a failing of the code. > 3. Some style issues > - use of "//" comments > - findOid should return bool, not int > > Sure will fix see attached patch > When you add support for user-defined types, that introduces a couple > other issues: > > 4. The format_binary GUC would depend on the search_path GUC, which > isn't great. > This is an interesting question. If the type isn't visible then it's not visible to the query so > > 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. > > > We've had this problem with binary for a long time, and it seems > desirable to solve it. But I'm not sure GUCs are the right way. > > How hard did you try to solve it in the protocol rather than with a > GUC? I see that the startup message allows protocol extensions by > prefixing a parameter name with "_pq_". Are protocol extensions > documented somewhere and would that be a reasonable thing to do here? > 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. > > Also, if we're going to make the binary format more practical to use, > can we document the expectations better? Yes we can do that. > It seems the expecatation is > that the binary format just never changes, and that if it does, that's > a new type name. > > I really hadn't considered supporting type names. I have asked Paul Ramsey about PostGIS and he doesn't see PostGIS using this. > Regards, > Jeff Davis > >
0002-style-issues-with.patch
Description: Binary data