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/