public inbox for [email protected]  

help / color / mirror / Atom feed

From: Álvaro Herrera <[email protected]>
To: David G. Johnston <[email protected]>
Cc: 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: Mon, 4 Aug 2025 13:22:04 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKFQuwbfCk-bD_rbNbf9QURKw8p1n99YwZy+bhzcpH6nnWZ9_g@mail.gmail.com>

On 2025-Jul-31, David G. Johnston wrote:

> > On Thu, Jul 31, 2025 at 8:05 PM Magnus Hagander <[email protected]>
> > wrote:

> > > I can agree that the "will likely be removed" is a bad wording, and
> > > clearly it was wrong :)

I disagree that this was clearly wrong -- you just haven't seen that
future yet.  It doesn't say "it will be removed before Postgres 20" or
"it will be removed by 2025", or "it will be removed before David
Johnston comes across this documentation again".  It says "will be
removed in an unspecified future version", which seems sufficiently
open-ended to me.

> > > 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.

We could change "will" to "might" or "may" or "could", but I think we
could also leave it well enough alone.  It doesn't actually hurt
anything, does it?

> 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.

You could add a bullet point to the TODO page in the wiki to complement
it, but I don't think you would remove the doc paragraph while it at;
instead it'd probably remain redundant until we actually implemented
extended stats on joins, and then we'd remove both.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

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], [email protected]
  Subject: Re: Lets prohibit predicting the future in the documentation.
  In-Reply-To: <[email protected]>

* 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