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.
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)
3. Some style issues
- use of "//" comments
- findOid should return bool, not int
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.
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.
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?
Also, if we're going to make the binary format more practical to use,
can we document the expectations better? It seems the expecatation is
that the binary format just never changes, and that if it does, that's
a new type name.
Regards,
Jeff Davis