On 06/07/19 19:27, Andres Freund wrote: > The problem is that I don't recognize a limiting principle: > > If we want NOT NULL information for clients, why don't we include the > underlying types for arrays, and the fields in composite types? What > about foreign keys? And unique keys?
This reminds me of an idea I had for a future fe/be protocol version, right after a talk by Alyssa Ritchie and Henrietta Dombrovskaya at the last 2Q PGConf. [1] It seems they had ended up designing a whole 'nother "protocol level" involving queries wrapping their results as JSON and an app layer that unwraps again, after trying a simpler first approach that was foiled by the inability to see into arrays and anonymous record types in the 'describe' response. I thought, in a new protocol rev, why not let the driver send additional 'describe' messages after the first one, to drill into structure of individual columns mentioned in the first response, before sending the 'execute' message? If it doesn't want the further detail, it doesn't have to ask. > And then we suddenly need tracking for all these, so we don't always > send out that information when we previously already did If it's up to the client driver, it can track what it needs or already has. I haven't looked too deeply into the replication protocol ... it happens under a kind of copy-both, right?, so maybe there's a way for the receiver to send some inquiries back, but maybe in a windowed, full-duplex way where it might have to buffer some incoming messages before getting the response to an inquiry message it sent. Would those be thinkable thoughts for a future protocol rev? Regards, -Chap [1] https://www.2qpgconf.com/schedule/information-exchange-techniques-for-javapostgresql-applications/
