Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id B07CF1337EBE for ; Thu, 14 Oct 2010 11:35:41 -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 68273-02 for ; Thu, 14 Oct 2010 14:35:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id EBDEE1337E45 for ; Thu, 14 Oct 2010 11:33:43 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o9EEXR8T017942; Thu, 14 Oct 2010 10:33:27 -0400 (EDT) To: Peter Eisentraut cc: Robert Haas , Josh Kupershmidt , pgsql-docs@postgresql.org Subject: Re: Documenting removal of nonnullvalue() and friends In-reply-to: <1287064708.9532.3.camel@vanquo.pezone.net> References: <1287064708.9532.3.camel@vanquo.pezone.net> Comments: In-reply-to Peter Eisentraut message dated "Thu, 14 Oct 2010 16:58:28 +0300" Date: Thu, 14 Oct 2010 10:33:26 -0400 Message-ID: <17941.1287066806@sss.pgh.pa.us> From: Tom Lane 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, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/23 X-Sequence-Number: 6164 Peter Eisentraut 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