Обсуждение: Inheritance mention

Do people feel we should continue documenting that Postgres pre-7.1
didn't reference child tables by default?

    (In releases before 7.1, <literal>ONLY</> was the default
    behavior.)  The default behavior can be modified by changing
    the <xref linkend="guc-sql-inheritance"> configuration option.

I see this mentioned four places in the documentation.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian escreveu:
> Do people feel we should continue documenting that Postgres pre-7.1
> didn't reference child tables by default?
>
No. IMHO we should remove references to unsupported releases from documentation.


--
   Euler Taveira de Oliveira
   http://www.timbira.com/

Euler Taveira de Oliveira <euler@timbira.com> writes:
> Bruce Momjian escreveu:
>> Do people feel we should continue documenting that Postgres pre-7.1
>> didn't reference child tables by default?
>>
> No. IMHO we should remove references to unsupported releases from documentation.

"Unsupported releases" is far too strict a criterion for this.  For
example, there are demonstrably still people using 7.2 (we had a
question about it just last week).  They will still appreciate these
notes when they get around to updating.

Pre-7.1 might indeed be old enough to cut, but how much are we really
saving?  Four sentences out of our current docs doesn't excite me ...

            regards, tom lane

On Mon, Apr 13, 2009 at 12:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Euler Taveira de Oliveira <euler@timbira.com> writes:
>> Bruce Momjian escreveu:
>>> Do people feel we should continue documenting that Postgres pre-7.1
>>> didn't reference child tables by default?
>>>
>> No. IMHO we should remove references to unsupported releases from documentation.
>
> "Unsupported releases" is far too strict a criterion for this.  For
> example, there are demonstrably still people using 7.2 (we had a
> question about it just last week).  They will still appreciate these
> notes when they get around to updating.
>
> Pre-7.1 might indeed be old enough to cut, but how much are we really
> saving?  Four sentences out of our current docs doesn't excite me ...

But since there's a doc set per version, it would make sense to stop
mentioning unsupported versions in the docs for supported versions,
no?  Or is this a FAQ thing we're talking about?

Scott Marlowe <scott.marlowe@gmail.com> writes:
> On Mon, Apr 13, 2009 at 12:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Pre-7.1 might indeed be old enough to cut, but how much are we really
>> saving? �Four sentences out of our current docs doesn't excite me ...

> But since there's a doc set per version, it would make sense to stop
> mentioning unsupported versions in the docs for supported versions,
> no?  Or is this a FAQ thing we're talking about?

The problem is what to tell people to read if they want to transition
from an unsupported version to a supported version.

If we really wanted to save some space, we could cut all the release
notes for pre-7.4 (soon pre-8.0) releases.  But somehow that doesn't
seem like a good idea.  What it would mainly accomplish is to make it
hard to find the old information when you wanted it.

            regards, tom lane

Tom Lane wrote:
> Scott Marlowe <scott.marlowe@gmail.com> writes:
> > On Mon, Apr 13, 2009 at 12:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Pre-7.1 might indeed be old enough to cut, but how much are we really
> >> saving? �Four sentences out of our current docs doesn't excite me ...
>
> > But since there's a doc set per version, it would make sense to stop
> > mentioning unsupported versions in the docs for supported versions,
> > no?  Or is this a FAQ thing we're talking about?
>
> The problem is what to tell people to read if they want to transition
> from an unsupported version to a supported version.
>
> If we really wanted to save some space, we could cut all the release
> notes for pre-7.4 (soon pre-8.0) releases.  But somehow that doesn't
> seem like a good idea.  What it would mainly accomplish is to make it
> hard to find the old information when you wanted it.

It is not a question of documention bulk but the burden of having users
wade through a paragraph that is much more complex because of the 7.1
mention.

I have applied the attached patch to remove mention of the 7.1 behavior
in alter_table and select;  I have kept the main documentation mentions
unchanged.  I also still reference the sql_inheritance GUC variable,
where there are more details.

Maybe I wasn't clear in my original posting;   I never wanted to remove
all mentions, but rather retain mentions in logical locations.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/ref/alter_table.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/alter_table.sgml,v
retrieving revision 1.104
diff -c -c -r1.104 alter_table.sgml
*** doc/src/sgml/ref/alter_table.sgml    11 Feb 2009 21:11:15 -0000    1.104
--- doc/src/sgml/ref/alter_table.sgml    15 Apr 2009 22:35:28 -0000
***************
*** 450,462 ****
         <para>
          The name (possibly schema-qualified) of an existing table to
          alter. If <literal>ONLY</> is specified, only that table is
!         altered. If <literal>ONLY</> is not specified, the table and all
!         its descendant tables (if any) are updated. <literal>*</> can be
!         appended to the table name to indicate that descendant tables are
!         to be altered, but in the current version, this is the default
!         behavior.  (In releases before 7.1, <literal>ONLY</> was the
!         default behavior.  The default can be altered by changing the
!         configuration parameter <xref linkend="guc-sql-inheritance">.)
         </para>
        </listitem>
       </varlistentry>
--- 450,459 ----
         <para>
          The name (possibly schema-qualified) of an existing table to
          alter. If <literal>ONLY</> is specified, only that table is
!         altered. If <literal>ONLY</> is not specified, the table and any
!         descendant tables are altered. The default can be changed
!         using the configuration parameter <xref
!         linkend="guc-sql-inheritance">.
         </para>
        </listitem>
       </varlistentry>
Index: doc/src/sgml/ref/select.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v
retrieving revision 1.120
diff -c -c -r1.120 select.sgml
*** doc/src/sgml/ref/select.sgml    2 Feb 2009 20:42:57 -0000    1.120
--- doc/src/sgml/ref/select.sgml    15 Apr 2009 22:35:32 -0000
***************
*** 271,282 ****
          The name (optionally schema-qualified) of an existing table or
          view.  If <literal>ONLY</> is specified, only that table is
          scanned.  If <literal>ONLY</> is not specified, the table and
!         all its descendant tables (if any) are scanned.  <literal>*</>
!         can be appended to the table name to indicate that descendant
!         tables are to be scanned, but in the current version, this is
!         the default behavior.  (In releases before 7.1,
!         <literal>ONLY</> was the default behavior.)  The default
!         behavior can be modified by changing the <xref
          linkend="guc-sql-inheritance"> configuration option.
         </para>
        </listitem>
--- 271,278 ----
          The name (optionally schema-qualified) of an existing table or
          view.  If <literal>ONLY</> is specified, only that table is
          scanned.  If <literal>ONLY</> is not specified, the table and
!         any descendant tables are scanned.  The default
!         behavior can be changed using the <xref
          linkend="guc-sql-inheritance"> configuration option.
         </para>
        </listitem>