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