head	1.20;
access;
symbols
	REL7_2_8:1.18
	REL7_2_7:1.18
	REL7_2_6:1.18
	REL7_2_5:1.18
	REL7_2_4:1.18
	REL7_2_3:1.18
	REL7_2_STABLE:1.18.0.2
	REL7_2:1.18
	REL7_2_RC2:1.18
	REL7_2_RC1:1.18
	REL7_2_BETA5:1.18
	REL7_2_BETA4:1.17
	REL7_2_BETA3:1.16
	REL7_2_BETA2:1.15
	REL7_2_BETA1:1.15
	REL7_1_2:1.13
	REL7_1_STABLE:1.13.0.2
	REL7_1_BETA:1.11
	REL7_1_BETA3:1.12
	REL7_1_BETA2:1.12
	REL7_1:1.13
	REL7_0_PATCHES:1.7.0.2
	REL7_0:1.7
	REL6_5_PATCHES:1.3.0.2
	REL6_5:1.3
	REL6_4:1.2.0.2
	release-6-3:1.1;
locks; strict;
comment	@# @;


1.20
date	2002.08.05.19.44.58;	author petere;	state dead;
branches;
next	1.19;

1.19
date	2002.04.13.17.17.29;	author tgl;	state Exp;
branches;
next	1.18;

1.18
date	2002.01.07.02.29.12;	author petere;	state Exp;
branches;
next	1.17;

1.17
date	2001.11.21.05.53.41;	author thomas;	state Exp;
branches;
next	1.16;

1.16
date	2001.11.19.03.58.23;	author tgl;	state Exp;
branches;
next	1.15;

1.15
date	2001.09.13.15.55.22;	author petere;	state Exp;
branches;
next	1.14;

1.14
date	2001.09.09.17.21.59;	author petere;	state Exp;
branches;
next	1.13;

1.13
date	2001.01.13.23.58.55;	author petere;	state Exp;
branches;
next	1.12;

1.12
date	2001.01.05.06.34.15;	author tgl;	state Exp;
branches;
next	1.11;

1.11
date	2000.07.02.22.00.23;	author momjian;	state Exp;
branches;
next	1.10;

1.10
date	2000.06.22.22.31.15;	author petere;	state Exp;
branches;
next	1.9;

1.9
date	2000.06.14.13.12.52;	author thomas;	state Exp;
branches;
next	1.8;

1.8
date	2000.06.09.01.43.56;	author momjian;	state Exp;
branches;
next	1.7;

1.7
date	2000.05.02.20.01.51;	author thomas;	state Exp;
branches
	1.7.2.1;
next	1.6;

1.6
date	2000.03.31.03.27.40;	author thomas;	state Exp;
branches;
next	1.5;

1.5
date	2000.03.26.18.32.26;	author petere;	state Exp;
branches;
next	1.4;

1.4
date	99.08.08.04.21.33;	author thomas;	state Exp;
branches;
next	1.3;

1.3
date	98.12.29.02.24.16;	author thomas;	state Exp;
branches;
next	1.2;

1.2
date	98.07.29.06.49.59;	author thomas;	state Exp;
branches;
next	1.1;

1.1
date	98.03.01.08.15.54;	author thomas;	state Exp;
branches;
next	;

1.7.2.1
date	2000.06.14.13.18.59;	author thomas;	state Exp;
branches;
next	;


desc
@@


1.20
log
@Forgot to add/remove files.
@
text
@<!--
$Header: /cvsroot/pgsql-server/doc/src/sgml/inherit.sgml,v 1.19 2002/04/13 17:17:29 tgl Exp $
-->

 <chapter id="inherit">
  <title>Inheritance</title>

  <para>
   Let's create two tables. The capitals  table  contains
   state  capitals  which  are also cities. Naturally, the
   capitals table should inherit from cities.

<programlisting>
CREATE TABLE cities (
    name            text,
    population      float,
    altitude        int     -- (in ft)
);

CREATE TABLE capitals (
    state           char(2)
) INHERITS (cities);
</programlisting>

   In this case, a row  of  capitals  <firstterm>inherits</firstterm>  all
   attributes  (name,  population,  and altitude) from its
   parent, cities.  The type  of  the  attribute  name  is
   <type>text</type>,  a  native  <productname>PostgreSQL</productname>  type  for variable length
   ASCII strings.  The type of the attribute population is
   <type>float</type>,  a  native <productname>PostgreSQL</productname> type for double precision
   floating-point numbers.  State capitals have  an  extra
   attribute, state, that shows their state.  In <productname>PostgreSQL</productname>,
   a  table  can inherit from zero or more other tables,
   and a query can reference either  all  rows  of  a
   table  or  all  rows of  a  table plus all of its
   descendants. 

   <note>
    <para>
     The inheritance hierarchy is actually a directed acyclic graph.
    </para>
   </note>
  </para>

  <para>
    For example, the  following  query finds the  names  of  all  cities,
    including  state capitals, that are located at an altitude 
    over 500ft:

    <programlisting>
SELECT name, altitude
    FROM cities
    WHERE altitude &gt; 500;
    </programlisting>

   which returns:

   <programlisting>
   name    | altitude
-----------+----------
 Las Vegas |     2174
 Mariposa  |     1953
 Madison   |      845
   </programlisting>
  </para>

  <para>
    On the other hand, the  following  query  finds
    all  the cities that are not state capitals and
    are situated at an altitude over 500ft:

   <programlisting>
SELECT name, altitude
    FROM ONLY cities
    WHERE altitude &gt; 500;

   name    | altitude
-----------+----------
 Las Vegas |     2174
 Mariposa  |     1953
   </programlisting>         
  </para>

  <para>
   Here the <quote>ONLY</quote> before cities indicates that the query should
   be  run over only cities and not tables below cities in the
   inheritance hierarchy.  Many of the  commands  that  we
   have  already discussed -- <command>SELECT</command>,
   <command>UPDATE</command> and <command>DELETE</command> --
   support this <quote>ONLY</quote> notation.
  </para>

  <para>
  In some cases you may wish to know which table a particular tuple
  originated from. There is a system column called
  <structfield>TABLEOID</structfield> in each table which can tell you the
  originating table:

   <programlisting>
    SELECT c.tableoid, c.name, c.altitude
    FROM cities c
    WHERE c.altitude &gt; 500;
   </programlisting>

   which returns:

   <programlisting>
 tableoid |   name    | altitude
----------+-----------+----------
   139793 | Las Vegas |     2174
   139793 | Mariposa  |     1953
   139798 | Madison   |      845
   </programlisting>

   (If you try to reproduce this example, you will probably get different
   numeric OIDs.)  By doing a join with pg_class you can see the actual table
   names:

   <programlisting>
    SELECT p.relname, c.name, c.altitude
    FROM cities c, pg_class p
    WHERE c.altitude &gt; 500 and c.tableoid = p.oid;
   </programlisting>

   which returns:

   <programlisting>
 relname  |   name    | altitude
----------+-----------+----------
 cities   | Las Vegas |     2174
 cities   | Mariposa  |     1953
 capitals | Madison   |      845
   </programlisting>
   
  </para>

  <note>
   <title>Deprecated</title> 
   <para>
     In previous versions of <productname>PostgreSQL</productname>, the
     default was not to get access to child tables. This was found to
     be error prone and is also in violation of SQL99. Under the old
     syntax, to get the sub-tables you append <literal>*</literal> to the table name.
     For example
<programlisting>
SELECT * from cities*;
</programlisting>
     You can still explicitly specify scanning child tables by appending
     <literal>*</literal>, as well as explicitly specify not scanning child tables by
     writing <quote>ONLY</quote>.  But beginning in version 7.1, the default
     behavior for an undecorated table name is to scan its child tables
     too, whereas before the default was not to do so.  To get the old
     default behavior, set the configuration option
     <literal>SQL_Inheritance</literal> to off, e.g.,
<programlisting>
SET SQL_Inheritance TO OFF;
</programlisting>
     or add a line in your <filename>postgresql.conf</filename> file.
   </para>
  </note>

  <para>
   A limitation of the inheritance feature is that indexes (including
   unique constraints) and foreign key constraints only apply to single
   tables, not to their inheritance children.  Thus, in the above example,
   specifying that another table's column <literal>REFERENCES cities(name)</>
   would allow the other table to contain city names but not capital names.
   This deficiency will probably be fixed in some future release.
  </para>

 </chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->
@


1.19
log
@Update/correct inheritance examples.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.18 2002/01/07 02:29:12 petere Exp $
@


1.18
log
@Editorial review
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.17 2001/11/21 05:53:41 thomas Exp $
d59 5
a63 9
+----------+----------+
|name      | altitude |
+----------+----------+
|Las Vegas | 2174     |
+----------+----------+
|Mariposa  | 1953     |
+----------+----------+
|Madison   | 845      |
+----------+----------+
d70 1
a70 1
    are situated at an altitude of 500ft or higher:
d77 4
a80 7
+----------+----------+
|name      | altitude |
+----------+----------+
|Las Vegas | 2174     |
+----------+----------+
|Mariposa  | 1953     |
+----------+----------+
d108 5
a112 9
+---------+----------+----------+
|tableoid |name      | altitude |
+---------+----------+----------+
|37292    |Las Vegas | 2174     |
+---------+----------+----------+
|37280    |Mariposa  | 1953     |
+---------+----------+----------+
|37280    |Madison   | 845      |
+---------+----------+----------+
d115 3
a117 1
   If you do a join with pg_class you can see the actual table name:
d128 5
a132 9
+---------+----------+----------+
|relname  |name      | altitude |
+---------+----------+----------+
|capitals |Las Vegas | 2174     |
+---------+----------+----------+
|cities   |Mariposa  | 1953     |
+---------+----------+----------+
|cities   |Madison   | 845      |
+---------+----------+----------+
@


1.17
log
@Deprecate 'current' for date/time input.
Fix up references to "PostgreSQL" rather than "Postgres". Was roughly
 evenly split between the two before. ref/ files not yet done.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.16 2001/11/19 03:58:23 tgl Exp $
d31 1
a31 1
   floating point numbers.  State capitals have  an  extra
@


1.16
log
@A bunch of small doco updates motivated by scanning the comments on
the interactive docs.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.15 2001/09/13 15:55:22 petere Exp $
d28 1
a28 1
   <type>text</type>,  a  native  <productname>Postgres</productname>  type  for variable length
d30 1
a30 1
   <type>float</type>,  a  native <productname>Postgres</productname> type for double precision
d32 1
a32 1
   attribute, state, that shows their state.  In <productname>Postgres</productname>,
d153 1
a153 1
     In previous versions of <productname>Postgres</productname>, the
@


1.15
log
@Replace ASCII-quotes with proper markup.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
d174 10
@


1.14
log
@Markup additions and spell check. (covers User's Guide)
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.13 2001/01/13 23:58:55 petere Exp $
d156 1
a156 1
     syntax, to get the sub-tables you append "*" to the table name.
d162 1
a162 1
     "*", as well as explicitly specify not scanning child tables by
@


1.13
log
@Terminology cleanup: class -> table, instance -> row, attribute -> column,
etc.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.12 2001/01/05 06:34:15 tgl Exp $
d40 1
a40 1
     The inheritance hierarchy is a actually a directed acyclic graph.
d103 1
a103 1
  <quote>TABLEOID</quote> in each table which can tell you the
@


1.12
log
@Remove not-really-standard implementation of CREATE TABLE's UNDER clause,
and revert documentation to describe the existing INHERITS clause
instead, per recent discussion in pghackers.  Also fix implementation
of SQL_inheritance SET variable: it is not cool to look at this var
during the initial parsing phase, only during parse_analyze().  See
recent bug report concerning misinterpretation of date constants just
after a SET TIMEZONE command.  gram.y really has to be an invariant
transformation of the query string to a raw parsetree; anything that
can vary with time must be done during parse analysis.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.11 2000/07/02 22:00:23 momjian Exp $
d9 1
a9 1
   Let's create two classes. The capitals  class  contains
d11 1
a11 1
   capitals class should inherit from cities.
d25 1
a25 1
   In this case, an  instance  of  capitals  <firstterm>inherits</firstterm>  all
d33 3
a35 3
   a  class  can inherit from zero or more other classes,
   and a query can reference either  all  instances  of  a
   class  or  all  instances  of  a  class plus all of its
d93 1
a93 1
   be  run over only cities and not classes below cities in the
d102 1
a102 1
  originated from. There is a system attribute called
d156 1
a156 1
     syntax, to get the sub-classes you append "*" to the table name.
@


1.11
log
@Attached is a new patch which addresses this problem. (oids in
regression tests).

Chris Bitmead
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.10 2000/06/22 22:31:15 petere Exp $
d20 1
a20 1
CREATE TABLE capitals UNDER cities (
d22 1
a22 1
);
d46 9
a54 9
   For example, the  following  query finds the  names  of  all  cities,
   including  state capitals, that are located at an altitude 
   over 500ft, the query is:

   <programlisting>
    SELECT c.name, c.altitude
    FROM cities c
    WHERE c.altitude > 500;
</programlisting>
d72 3
a74 3
   On the other hand, the  following  query  finds
   all  the cities, but not capital cities 
   that are situated at an attitude of 500ft or higher:
d77 1
a77 1
    SELECT name, altitude
d109 1
a109 1
    WHERE c.altitude > 500;
d131 1
a131 1
    WHERE c.altitude > 500 and c.tableoid = p.oid;
d153 5
a157 5
    In previous versions of <productname>Postgres</productname>, the
    default was not to get access to child tables. This was found to
    be error prone and is also in violation of SQL. Under the old
    syntax, to get the sub-classes you append "*" to the table name.
    For example
d161 7
a167 2
    To get the old behavior, the set configuration option
    <literal>SQL_Inheritance</literal> to off, e.g.,
d171 1
a171 1
    or add a line in your <filename>postgresql.conf</filename> file.
@


1.10
log
@Second pass over run-time configuration system. Adjust priorities on some
option settings. Sort out SIGHUP vs BACKEND -- there is no total ordering
here, so make explicit checks. Add comments explaining all of this.
Removed permissions check on SHOW command.

Add examine_subclass to the game, rename to SQL_inheritance to fit the
official data model better. Adjust documentation.

Standalone backend needs to reset all options before it starts. To
facilitate that, have IsUnderPostmaster be set by the postmaster itself,
don't wait for the magic -p switch.

Also make sure that all environment variables and argv's survive
init_ps_display(). Use strdup where necessary.

Have initdb make configuration files (postgresql.conf, pg_hba.conf) mode
0600 -- having configuration files is no fun if you can't edit them.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.9 2000/06/14 13:12:52 thomas Exp $
d99 51
@


1.9
log
@Repair markup to allow clean doc builds.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.8 2000/06/09 01:43:56 momjian Exp $
d99 19
a117 13
  <para>
  Deprecated: In previous versions of postgres, the default was not to
  get access to child classes. By experience this was found to be error
  prone. Under the old syntax, to get the sub-classes you append "*"
  to the table name. For example
   <programlisting>
   SELECT * from cities*;
   </programlisting>     
   This old behaviour is still available by using a SET command...    
   <programlisting>
   SET EXAMINE_SUBCLASS TO on;
   </programlisting>     
  </para>
@


1.8
log
@Inheritance overhaul by  Chris Bitmead <chris@@bitmead.com>
@
text
@d2 1
a2 1
$Header: /usr/local/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.7 2000/05/02 20:01:51 thomas Exp $
d43 1
d91 1
@


1.7
log
@Fixups in content and markup for 7.0 release.
@
text
@d2 1
a2 1
$Header: /usr/local/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.6 2000/03/31 03:27:40 thomas Exp $
d20 1
a20 1
CREATE TABLE capitals (
d22 1
a22 1
) INHERITS (cities);
a43 16
   For example, the  following  query  finds
   all  the cities that are situated at an attitude of 500ft or higher:

<programlisting>
SELECT name, altitude
    FROM cities
    WHERE altitude &gt; 500;

   name    | altitude
-----------+----------
 Las Vegas |     2174
 Mariposa  |     1953
(2 rows)
</programlisting>         
  </para>

d45 1
a45 1
   On the other hand, to find the  names  of  all  cities,
d49 3
a51 3
<programlisting>
SELECT c.name, c.altitude
    FROM cities* c
d57 32
a88 7
<programlisting>
   name    | altitude
-----------+----------
 Las Vegas |     2174
 Mariposa  |     1953
 Madison   |      845
</programlisting>
d90 2
a91 2
   Here the "*" after cities indicates that the query should
   be  run over cities and all classes below cities in the
d95 14
a108 2
   support this "*" notation, as do others, like
   <command>ALTER TABLE</command>.
@


1.7.2.1
log
@Fix markup to allow doc building.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/inherit.sgml,v 1.7 2000/05/02 20:01:51 thomas Exp $
a42 1
  </para>
a89 1
  <para>
@


1.6
log
@Minor markup changes. Refer to (".../catalog") in the emacs hints.
@
text
@d2 1
a2 1
$Header$
d81 1
a81 1
   Here the <quote>*</quote> after cities indicates that the query should
d86 1
a86 1
   support this <quote>*</quote> notation, as do others, like
@


1.5
log
@Updated user's guide to match new psql's output format
Fixed bug in createdb/alternative location
@
text
@d1 4
d93 1
a93 1
mode: sgml
d103 1
a103 1
sgml-local-catalogs:"/usr/lib/sgml/catalog"
@


1.4
log
@Update references to char2 type by using char(2).
Thanks to Garr Updegraff <garru@@uci.edu> for the tip.
@
text
@d9 1
a9 1
   <programlisting>
d19 1
a19 1
   </programlisting>
d43 1
a43 1
   <programlisting>
d48 6
a53 8
+----------+----------+
|name      | altitude |
+----------+----------+
|Las Vegas | 2174     |
+----------+----------+
|Mariposa  | 1953     |
+----------+----------+
   </programlisting>         
d61 1
a61 1
   <programlisting>
d65 1
a65 1
   </programlisting>
d69 7
a75 11
   <programlisting>
+----------+----------+
|name      | altitude |
+----------+----------+
|Las Vegas | 2174     |
+----------+----------+
|Mariposa  | 1953     |
+----------+----------+
|Madison   | 845      |
+----------+----------+
   </programlisting>
@


1.3
log
@Clean up to ensure tag completion as required by the newest versions
 of Norm's Modular Style Sheets and jade/docbook.
From Vince Vielhaber <vev@@michvhf.com>.
@
text
@d1 2
a2 2
<Chapter Id="inherit">
<Title>Inheritance</Title>
d4 6
a9 6
<Para>
     Let's create two classes. The capitals  class  contains
     state  capitals  which  are also cities. Naturally, the
     capitals class should inherit from cities.
     
<ProgramListing>
d13 1
a13 1
    altitude        int            -- (in ft)
d17 1
a17 1
    state           char2
d19 23
a41 1
</ProgramListing>
d43 1
a43 21
     In this case, an  instance  of  capitals  <FirstTerm>inherits</FirstTerm>  all
     attributes  (name,  population,  and altitude) from its
     parent, cities.  The type  of  the  attribute  name  is
     <Type>text</Type>,  a  native  <ProductName>Postgres</ProductName>  type  for variable length
     ASCII strings.  The type of the attribute population is
     <Type>float</Type>,  a  native <ProductName>Postgres</ProductName> type for double precision
     floating point numbers.  State capitals have  an  extra
     attribute, state, that shows their state.  In <ProductName>Postgres</ProductName>,
     a  class  can inherit from zero or more other classes,
     and a query can reference either  all  instances  of  a
     class  or  all  instances  of  a  class plus all of its
     descendants. 
<Note>
<Para>
The inheritance hierarchy is a actually a directed acyclic graph.
</Para>
</Note>
For example, the  following  query  finds
     all  the cities that are situated at an attitude of 500ft or higher:
     
<ProgramListing>
d55 2
a56 2
</ProgramListing>         
</para>
d58 4
a61 4
<Para>
     On the other hand, to find the  names  of  all  cities,
     including  state capitals, that are located at an altitude 
     over 500ft, the query is:
d63 1
a63 1
<ProgramListing>
d67 1
a67 1
</ProgramListing>
d69 3
a71 3
     which returns:
     
<ProgramListing>
d81 1
a81 8
</ProgramListing>

     Here the <Quote>*</Quote> after cities indicates that the query should
     be  run over cities and all classes below cities in the
     inheritance hierarchy.  Many of the  commands  that  we
     have  already discussed -- <Command>select</Command>, <Command>update</Command> and <Command>delete</Command> --
     support this <Quote>*</Quote> notation, as do others, like <Command>alter</Command>.
</Para>
d83 26
a108 1
</Chapter>
@


1.2
log
@Add id field to chapter and book tags to allow output file names
 to be meaningful.
@
text
@d54 1
@


1.1
log
@SGML source for new documentation.
@
text
@d1 1
a1 1
<Chapter>
@
