public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Smith <[email protected]>
To: Magnus Hagander <[email protected]>
Cc: David Rowley <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: PostgreSQL Documentation <[email protected]>
Subject: Re: Lets prohibit predicting the future in the documentation.
Date: Fri, 1 Aug 2025 09:23:41 +1000
Message-ID: <CAHut+PtxFF_it0QAqhYgu1ThDvbcMfeyXTpOAYsi5VEvO5jJfQ@mail.gmail.com> (raw)
In-Reply-To: <CABUevEyYJxOrqKMLsxccmTCu=i2XxZLXMi-23aEz6XZWaG9hfg@mail.gmail.com>
References: <CAKFQuwbSr8xR5mHN008sAxK2rvVLEuZ01exuekT1nCB+YVgFrg@mail.gmail.com>
<CAApHDvqPfrexkVLBM-KYYMDLDjh=VW8TykqZeX7w--5hv+oN4g@mail.gmail.com>
<CABUevEyYJxOrqKMLsxccmTCu=i2XxZLXMi-23aEz6XZWaG9hfg@mail.gmail.com>
On Thu, Jul 31, 2025 at 8:05 PM Magnus Hagander <[email protected]> wrote:
>
>
>
> On Thu, Jul 31, 2025 at 5:03 AM David Rowley <[email protected]> wrote:
>>
>> On Thu, 31 Jul 2025 at 14:17, David G. Johnston
>> <[email protected]> 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
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Lets prohibit predicting the future in the documentation.
In-Reply-To: <CAHut+PtxFF_it0QAqhYgu1ThDvbcMfeyXTpOAYsi5VEvO5jJfQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox