On Mon, 15 Apr 2024 at 13:19, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Michael Paquier <michael@paquier.xyz> writes: > > On Mon, Apr 15, 2024 at 11:20:16AM +1200, David Rowley wrote: > >> 1. We cannot change Node enums in minor versions > >> 2. We're *unlikely* to add fields to Node types in minor versions, and > >> if we did we'd likely be leaving them out of the jumble calc, plus it > >> seems highly unlikely any new field we wedged into the padding would > >> relate at all to the parsed query. > > > Since 16 these new fields would be added by default unless the node > > attribute query_jumble_ignore is appended to it. > > They'd also be written/read by outfuncs/readfuncs, thereby breaking > stored views/rules if the Node is one that can appear in a parsetree. > So the bar to making such a change in a stable branch would be very > high.
I think a soft guarantee in the docs for it being stable in minor versions would be ok then.
I'm unsure if "Rule of thumb" is the correct way to convey that. We can't really write "We endeavour to", as who is "We". Maybe something like "Generally, it can be assumed that queryid is stable between all minor versions of a major version of ..., providing that <other reasons>".
So, there are three kinds of dependencies:
Product
Machine
User Data
The user data dependencies are noted as being OID among other things
The machine dependencies are the architecture and other facets
The product dependencies are not enumerated but can be simply stated to be internals stable throughout a major version.
A minimal rewording of the last sentence in the prior paragraph could be:
Lastly, the queryid depends upon aspects of PostgreSQL internals that can only change with each major version release.
I'm disinclined to note minor releases here given the above wording. Sure, like with lots of things, circumstances may require us to break a policy, but we don't seem to make that point everywhere we conceive it could happen.
