Re: protocol-level wait-for-LSN

On Wed, Oct 30, 2024 at 6:45 PM Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
> doesn't work, right? I don't like clients need to know the exact order
> of each protocol extensions.

I agree with this criticism, at least for the most part. Years and
years ago, the only way to specify EXPLAIN options was to say EXPLAIN
[ANALYZE] [VERBOSE] query. So, if you said, EXPLAIN VERBOSE ANALYZE
query, it didn't work. Actually, it still doesn't, but now you can say
EXPLAIN (VERBOSE, ANALYZE) query and that will work, because the new
options syntax allows for options to be specified in any order. And a
really key point here is that for quite a while we were resistant to
adding any new EXPLAIN options precisely because everyone knew the
requirement to mention the options in a specific order did not scale.
We could reasonably ask users to remember that ANALYZE had to come
before VERBOSE, but asking people to remember the correct order of
three or six or ten options would end up being quite annoying.

And I think the problem here is the same. When you want to add the
first set of optional fields to a protocol message, it seems perfectly
reasonable to decide that _pq_.tde=1 or _pq_.wait_for_lsn=1 turns them
on. When you add the second set of fields, it probably still feels
reasonable. But when you get up to half a dozen or so protocol
extensions that affect the same underlying set of messages, it's going
to start to be pretty annoying. Parsing that protocol message is going
to require pretty complicated code. Even if you don't care about the
contents of the extra fields, you still potentially need code to
understand and ignore them, unless you refuse support for the protocol
extension altogether.

Now, what makes this case less of a problem than the EXPLAIN case
mentioned above is that people are not typically going to construct
protocol messages by hand. As long as the protocol documentation is
clear about the ordering of fields and which fields are controlled by
which options, maybe it's not too horrible if everybody has to go
through and write a bunch of if-statements. But even so, wouldn't it
be easier if protocol extensions only added new message types instead
of redefining existing ones? Then you could just ignore message types
you don't care about. To be clear, I'm not saying that we should
never, ever extend an existing message type. I'm just saying that the
design of cramming a bunch of new fields into a message type doesn't
seem entirely scalable, and therefore I believe we should consider
whether there are reasonable alternatives.

--
Robert Haas
EDB: http://www.enterprisedb.com