MIME-Version: 1.0
References: 
 <CAKFQuwbSr8xR5mHN008sAxK2rvVLEuZ01exuekT1nCB+YVgFrg@mail.gmail.com>
 <CAApHDvqPfrexkVLBM-KYYMDLDjh=VW8TykqZeX7w--5hv+oN4g@mail.gmail.com>
 <CABUevEyYJxOrqKMLsxccmTCu=i2XxZLXMi-23aEz6XZWaG9hfg@mail.gmail.com>
In-Reply-To: 
 <CABUevEyYJxOrqKMLsxccmTCu=i2XxZLXMi-23aEz6XZWaG9hfg@mail.gmail.com>
From: Peter Smith <smithpb2250@gmail.com>
Date: Fri, 1 Aug 2025 09:23:41 +1000
Message-ID: 
 <CAHut+PtxFF_it0QAqhYgu1ThDvbcMfeyXTpOAYsi5VEvO5jJfQ@mail.gmail.com>
Subject: Re: Lets prohibit predicting the future in the documentation.
To: Magnus Hagander <magnus@hagander.net>
Cc: David Rowley <dgrowleyml@gmail.com>,
 "David G. Johnston" <david.g.johnston@gmail.com>,
	PostgreSQL Documentation <pgsql-docs@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHut%2BPtxFF_it0QAqhYgu1ThDvbcMfeyXTpOAYsi5VEvO5jJfQ%40mail.gmail.com>
Precedence: bulk

On Thu, Jul 31, 2025 at 8:05=E2=80=AFPM Magnus Hagander <magnus@hagander.ne=
t> wrote:
>
>
>
> On Thu, Jul 31, 2025 at 5:03=E2=80=AFAM David Rowley <dgrowleyml@gmail.co=
m> wrote:
>>
>> On Thu, 31 Jul 2025 at 14:17, David G. Johnston
>> <david.g.johnston@gmail.com> wrote:
>> >
>> > Came across this again today...we added, way back in v11:
>> >
>> > "This limitation will likely be removed in a future version of <produc=
tname>PostgreSQL</productname>."
>> >
>> > https://www.postgresql.org/docs/18/sql-createstatistics.html
>>
>> This sort of thing doesn't particularly upset me. I don't believe we
>> should hide the fact that certain features might need more work. If it
>> inspires someone to work on making improvements, wouldn't it be
>> worthwhile keeping these? A huge amount of stuff gets done around here
>> because people find some inspiration to make things better. I don't
>> believe all those people need to experience the problems first-hand to
>> be able to fix them. Plenty of people arrive here just looking to get
>> involved and make a difference. I presume that something like this
>> being mentioned in the docs likely has a much better "we actually want
>> this feature" ratio than the TODO list does. I also imagine it's more
>> likely to inspire users of PostgreSQL to get involved in developing
>> than the TODO list is.
>>
>> -1 from me.
>
>
> I can agree that the "will likely be removed" is a bad wording, and clear=
ly it was wrong :) But  something like "could be removed" would convey the =
important message that it is not a limitation of the concept itself, it's j=
ust something that hasn't been done yet -- and would perhaps encourage exac=
tly the sort of thing yuo'r suggesting. Where as "will likely be removed" a=
lmost sounds like someone is already working on it.
>

FYI, there are quite a lot like this. Mostly the docs are worded using
"may/might/can" rather than "will" be changed.

Some examples (e.g. search .sgml for "future")

... but this may change in future releases.

... These will probably be fixed in future releases:

... An area for future development is to ...

... restriction that may be lifted in a future version ...

... this might be replaced by a different mechanism in the future.

... This may be changed in a future release ...

... might change in a future release.

... This information describes possible future behavior.

... some of these restrictions might be loosened in a future release.

... (this behavior might change in the future).

... These can and probably will be fixed in future releases:

... These deficiencies may be remedied in future versions ...

... It is hoped that a future version of this module will ...

... This restriction on ... may be lifted in a future version

... These might be addressed in future releases.

... This may be expanded in the future.

... might be changed in a future release.

... This is an implementation restriction that might be fixed in
future releases.

=3D=3D=3D=3D=3D=3D
Kind Regards,
Peter Smith.
Fujitsu Australia