Re: Documenting removal of nonnullvalue() and friends

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Kupershmidt <schmiddy(at)gmail(dot)com>, pgsql-docs(at)postgresql(dot)org
Subject: Re: Documenting removal of nonnullvalue() and friends
Date: 2010-10-14 14:33:26
Message-ID: 17941.1287066806@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tor, 2010-10-14 at 08:50 -0400, Robert Haas wrote:
>> Still, I don't think it would be unreasonable to add a note to the
>> prior-release documentation saying - hey, these functions exist. They
>> are for internal use only, and do not exist in later versions. Don't
>> use 'em. Now, how many people will actually see that note? Probably
>> not many. But it wouldn't bother me to have it there.

> Just like there is a philosophical argument against changing the release
> notes after the release, there is an argument against changing a past
> release to "retroactively predict" how future releases behave. We have
> made exceptions to both points on occasion, but usually only for
> critical upgrade-related issues.

I would put this whole issue in the category of "if you use undocumented
features, you should not be surprised when they undocumentedly break".
There are many many places where it's possible to see undocumented
implementation details in Postgres. If we put in release-note warnings
every time we changed one of those details, the release notes would be
twice as long and half as useful as they are now.

regards, tom lane

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2010-10-14 14:38:11 Re: Documenting removal of nonnullvalue() and friends
Previous Message Josh Kupershmidt 2010-10-14 14:29:42 Re: Documenting removal of nonnullvalue() and friends