Re: Lets prohibit predicting the future in the documentation.

On Thu, Jul 31, 2025 at 8:05 PM Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
>
>
> On Thu, Jul 31, 2025 at 5:03 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>>
>> On Thu, 31 Jul 2025 at 14:17, David G. Johnston
>> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>> >
>> > Came across this again today...we added, way back in v11:
>> >
>> > "This limitation will likely be removed in a future version of <productname>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 clearly 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 just something that hasn't been done yet -- and would perhaps encourage exactly the sort of thing yuo'r suggesting. Where as "will likely be removed" almost 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.

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