Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id AA7011337D31 for ; Thu, 14 Oct 2010 11:26:12 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 44001-05 for ; Thu, 14 Oct 2010 14:25:32 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mail.postgresql.org (Postfix) with SMTP id 4584D1337D20 for ; Thu, 14 Oct 2010 11:25:13 -0300 (ADT) Received: (qmail invoked by alias); 14 Oct 2010 13:58:31 -0000 Received: from a88-115-218-165.elisa-laajakaista.fi (EHLO [10.0.0.101]) [88.115.218.165] by mail.gmx.net (mp023) with SMTP; 14 Oct 2010 15:58:31 +0200 X-Authenticated: #495269 X-Provags-ID: V01U2FsdGVkX1+On79yUieO78Z9KiRaf3+Q84sIoflJbItDBBfLUD 5kkosxzjYtp0zV Subject: Re: Documenting removal of nonnullvalue() and friends From: Peter Eisentraut To: Robert Haas Cc: Josh Kupershmidt , pgsql-docs@postgresql.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 14 Oct 2010 16:58:28 +0300 Message-ID: <1287064708.9532.3.camel@vanquo.pezone.net> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/21 X-Sequence-Number: 6162 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.