On Wed, Oct 30, 2024 at 6:45 PM Tatsuo Ishii <is...@postgresql.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
