Re: Stability of queryid in minor versions - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Stability of queryid in minor versions
Date
Msg-id CAKFQuwY-Xc8Gm3OKcqi=iZ-vJxY5pogmGe+SGk_eH_JbaY49iQ@mail.gmail.com
Whole thread Raw
In response to Re: Stability of queryid in minor versions  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Sun, Apr 14, 2024 at 6:32 PM David Rowley <dgrowleyml@gmail.com> wrote:
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.

David J.

pgsql-hackers by date:

Previous
From: "Yusuke Egashira (Fujitsu)"
Date:
Subject: [MASSMAIL] Resetting synchronous_standby_names can wait for CHECKPOINT to finish
Next
From: David Rowley
Date:
Subject: Re: Stability of queryid in minor versions