public inbox for [email protected]
help / color / mirror / Atom feedFrom: David G. Johnston <[email protected]>
To: Peter Smith <[email protected]>
Cc: Magnus Hagander <[email protected]>
Cc: David Rowley <[email protected]>
Cc: PostgreSQL Documentation <[email protected]>
Subject: Re: Lets prohibit predicting the future in the documentation.
Date: Thu, 31 Jul 2025 16:39:08 -0700
Message-ID: <CAKFQuwbfCk-bD_rbNbf9QURKw8p1n99YwZy+bhzcpH6nnWZ9_g@mail.gmail.com> (raw)
In-Reply-To: <CAHut+PtxFF_it0QAqhYgu1ThDvbcMfeyXTpOAYsi5VEvO5jJfQ@mail.gmail.com>
References: <CAKFQuwbSr8xR5mHN008sAxK2rvVLEuZ01exuekT1nCB+YVgFrg@mail.gmail.com>
<CAApHDvqPfrexkVLBM-KYYMDLDjh=VW8TykqZeX7w--5hv+oN4g@mail.gmail.com>
<CABUevEyYJxOrqKMLsxccmTCu=i2XxZLXMi-23aEz6XZWaG9hfg@mail.gmail.com>
<CAHut+PtxFF_it0QAqhYgu1ThDvbcMfeyXTpOAYsi5VEvO5jJfQ@mail.gmail.com>
On Thu, Jul 31, 2025 at 4:24 PM Peter Smith <[email protected]> wrote:
> 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.
>
>
Yeah, I haven't been able to dig into the source yet on this topic but
basically that says to me that lots of people, with good intentions, want
to couch bad news (limitations) with something positive (hope). But in the
documentation it ends up almost inevitably turning into false hope.
There is no good way to extract all these "TODO" items from the HTML docs
and seems like a non-optimal method for transferring knowledge to potential
developers who may choose to try and remove such limitations.
David J.
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: <CAKFQuwbfCk-bD_rbNbf9QURKw8p1n99YwZy+bhzcpH6nnWZ9_g@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