begriffs open source - ai-pg/blob - full-docs/src/sgml/html/ddl-inherit.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>5.11. Inheritance</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="ddl-schemas.html" title="5.10. Schemas" /><link rel="next" href="ddl-partitioning.html" title="5.12. Table Partitioning" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">5.11. Inheritance</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="ddl-schemas.html" title="5.10. Schemas">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="ddl.html" title="Chapter 5. Data Definition">Up</a></td><th width="60%" align="center">Chapter 5. Data Definition</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="ddl-partitioning.html" title="5.12. Table Partitioning">Next</a></td></tr></table><hr /></div><div class="sect1" id="DDL-INHERIT"><div class="titlepage"><div><div><h2 class="title" style="clear: both">5.11. Inheritance <a href="#DDL-INHERIT" class="id_link">#</a></h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="ddl-inherit.html#DDL-INHERIT-CAVEATS">5.11.1. Caveats</a></span></dt></dl></div><a id="id-1.5.4.13.2" class="indexterm"></a><a id="id-1.5.4.13.3" class="indexterm"></a><p>
   3    <span class="productname">PostgreSQL</span> implements table inheritance,
   4    which can be a useful tool for database designers.  (SQL:1999 and
   5    later define a type inheritance feature, which differs in many
   6    respects from the features described here.)
   7   </p><p>
   8    Let's start with an example: suppose we are trying to build a data
   9    model for cities.  Each state has many cities, but only one
  10    capital. We want to be able to quickly retrieve the capital city
  11    for any particular state. This can be done by creating two tables,
  12    one for state capitals and one for cities that are not
  13    capitals. However, what happens when we want to ask for data about
  14    a city, regardless of whether it is a capital or not? The
  15    inheritance feature can help to resolve this problem. We define the
  16    <code class="structname">capitals</code> table so that it inherits from
  17    <code class="structname">cities</code>:
  18
  19 </p><pre class="programlisting">
  20 CREATE TABLE cities (
  21     name            text,
  22     population      float,
  23     elevation       int     -- in feet
  24 );
  25
  26 CREATE TABLE capitals (
  27     state           char(2)
  28 ) INHERITS (cities);
  29 </pre><p>
  30
  31    In this case, the <code class="structname">capitals</code> table <em class="firstterm">inherits</em>
  32    all the columns of its parent table, <code class="structname">cities</code>. State
  33    capitals also have an extra column, <code class="structfield">state</code>, that shows
  34    their state.
  35   </p><p>
  36    In <span class="productname">PostgreSQL</span>, a table can inherit from
  37    zero or more other tables, and a query can reference either all
  38    rows of a table or all rows of a table plus all of its descendant tables.
  39    The latter behavior is the default.
  40    For example, the following query finds the names of all cities,
  41    including state capitals, that are located at an elevation over
  42    500 feet:
  43
  44 </p><pre class="programlisting">
  45 SELECT name, elevation
  46     FROM cities
  47     WHERE elevation &gt; 500;
  48 </pre><p>
  49
  50    Given the sample data from the <span class="productname">PostgreSQL</span>
  51    tutorial (see <a class="xref" href="tutorial-sql-intro.html" title="2.1. Introduction">Section 2.1</a>), this returns:
  52
  53 </p><pre class="programlisting">
  54    name    | elevation
  55 -----------+-----------
  56  Las Vegas |      2174
  57  Mariposa  |      1953
  58  Madison   |       845
  59 </pre><p>
  60   </p><p>
  61    On the other hand, the following query finds all the cities that
  62    are not state capitals and are situated at an elevation over 500 feet:
  63
  64 </p><pre class="programlisting">
  65 SELECT name, elevation
  66     FROM ONLY cities
  67     WHERE elevation &gt; 500;
  68
  69    name    | elevation
  70 -----------+-----------
  71  Las Vegas |      2174
  72  Mariposa  |      1953
  73 </pre><p>
  74   </p><p>
  75    Here the <code class="literal">ONLY</code> keyword indicates that the query
  76    should apply only to <code class="structname">cities</code>, and not any tables
  77    below <code class="structname">cities</code> in the inheritance hierarchy.  Many
  78    of the commands that we have already discussed —
  79    <code class="command">SELECT</code>, <code class="command">UPDATE</code> and
  80    <code class="command">DELETE</code> — support the
  81    <code class="literal">ONLY</code> keyword.
  82   </p><p>
  83    You can also write the table name with a trailing <code class="literal">*</code>
  84    to explicitly specify that descendant tables are included:
  85
  86 </p><pre class="programlisting">
  87 SELECT name, elevation
  88     FROM cities*
  89     WHERE elevation &gt; 500;
  90 </pre><p>
  91
  92    Writing <code class="literal">*</code> is not necessary, since this behavior is always
  93    the default.  However, this syntax is still supported for
  94    compatibility with older releases where the default could be changed.
  95   </p><p>
  96    In some cases you might wish to know which table a particular row
  97    originated from. There is a system column called
  98    <code class="structfield">tableoid</code> in each table which can tell you the
  99    originating table:
 100
 101 </p><pre class="programlisting">
 102 SELECT c.tableoid, c.name, c.elevation
 103 FROM cities c
 104 WHERE c.elevation &gt; 500;
 105 </pre><p>
 106
 107    which returns:
 108
 109 </p><pre class="programlisting">
 110  tableoid |   name    | elevation
 111 ----------+-----------+-----------
 112    139793 | Las Vegas |      2174
 113    139793 | Mariposa  |      1953
 114    139798 | Madison   |       845
 115 </pre><p>
 116
 117    (If you try to reproduce this example, you will probably get
 118    different numeric OIDs.)  By doing a join with
 119    <code class="structname">pg_class</code> you can see the actual table names:
 120
 121 </p><pre class="programlisting">
 122 SELECT p.relname, c.name, c.elevation
 123 FROM cities c, pg_class p
 124 WHERE c.elevation &gt; 500 AND c.tableoid = p.oid;
 125 </pre><p>
 126
 127    which returns:
 128
 129 </p><pre class="programlisting">
 130  relname  |   name    | elevation
 131 ----------+-----------+-----------
 132  cities   | Las Vegas |      2174
 133  cities   | Mariposa  |      1953
 134  capitals | Madison   |       845
 135 </pre><p>
 136   </p><p>
 137    Another way to get the same effect is to use the <code class="type">regclass</code>
 138    alias type, which will print the table OID symbolically:
 139
 140 </p><pre class="programlisting">
 141 SELECT c.tableoid::regclass, c.name, c.elevation
 142 FROM cities c
 143 WHERE c.elevation &gt; 500;
 144 </pre><p>
 145   </p><p>
 146    Inheritance does not automatically propagate data from
 147    <code class="command">INSERT</code> or <code class="command">COPY</code> commands to
 148    other tables in the inheritance hierarchy. In our example, the
 149    following <code class="command">INSERT</code> statement will fail:
 150 </p><pre class="programlisting">
 151 INSERT INTO cities (name, population, elevation, state)
 152 VALUES ('Albany', NULL, NULL, 'NY');
 153 </pre><p>
 154    We might hope that the data would somehow be routed to the
 155    <code class="structname">capitals</code> table, but this does not happen:
 156    <code class="command">INSERT</code> always inserts into exactly the table
 157    specified.  In some cases it is possible to redirect the insertion
 158    using a rule (see <a class="xref" href="rules.html" title="Chapter 39. The Rule System">Chapter 39</a>).  However that does not
 159    help for the above case because the <code class="structname">cities</code> table
 160    does not contain the column <code class="structfield">state</code>, and so the
 161    command will be rejected before the rule can be applied.
 162   </p><p>
 163    All check constraints and not-null constraints on a parent table are
 164    automatically inherited by its children, unless explicitly specified
 165    otherwise with <code class="literal">NO INHERIT</code> clauses.  Other types of constraints
 166    (unique, primary key, and foreign key constraints) are not inherited.
 167   </p><p>
 168    A table can inherit from more than one parent table, in which case it has
 169    the union of the columns defined by the parent tables.  Any columns
 170    declared in the child table's definition are added to these.  If the
 171    same column name appears in multiple parent tables, or in both a parent
 172    table and the child's definition, then these columns are <span class="quote">“<span class="quote">merged</span>”</span>
 173    so that there is only one such column in the child table.  To be merged,
 174    columns must have the same data types, else an error is raised.
 175    Inheritable check constraints and not-null constraints are merged in a
 176    similar fashion.  Thus, for example, a merged column will be marked
 177    not-null if any one of the column definitions it came from is marked
 178    not-null.  Check constraints are merged if they have the same name,
 179    and the merge will fail if their conditions are different.
 180   </p><p>
 181    Table inheritance is typically established when the child table is
 182    created, using the <code class="literal">INHERITS</code> clause of the
 183    <a class="link" href="sql-createtable.html" title="CREATE TABLE"><code class="command">CREATE TABLE</code></a>
 184    statement.
 185    Alternatively, a table which is already defined in a compatible way can
 186    have a new parent relationship added, using the <code class="literal">INHERIT</code>
 187    variant of <a class="link" href="sql-altertable.html" title="ALTER TABLE"><code class="command">ALTER TABLE</code></a>.
 188    To do this the new child table must already include columns with
 189    the same names and types as the columns of the parent. It must also include
 190    check constraints with the same names and check expressions as those of the
 191    parent. Similarly an inheritance link can be removed from a child using the
 192    <code class="literal">NO INHERIT</code> variant of <code class="command">ALTER TABLE</code>.
 193    Dynamically adding and removing inheritance links like this can be useful
 194    when the inheritance relationship is being used for table
 195    partitioning (see <a class="xref" href="ddl-partitioning.html" title="5.12. Table Partitioning">Section 5.12</a>).
 196   </p><p>
 197    One convenient way to create a compatible table that will later be made
 198    a new child is to use the <code class="literal">LIKE</code> clause in <code class="command">CREATE
 199    TABLE</code>. This creates a new table with the same columns as
 200    the source table. If there are any <code class="literal">CHECK</code>
 201    constraints defined on the source table, the <code class="literal">INCLUDING
 202    CONSTRAINTS</code> option to <code class="literal">LIKE</code> should be
 203    specified, as the new child must have constraints matching the parent
 204    to be considered compatible.
 205   </p><p>
 206    A parent table cannot be dropped while any of its children remain. Neither
 207    can columns or check constraints of child tables be dropped or altered
 208    if they are inherited
 209    from any parent tables. If you wish to remove a table and all of its
 210    descendants, one easy way is to drop the parent table with the
 211    <code class="literal">CASCADE</code> option (see <a class="xref" href="ddl-depend.html" title="5.15. Dependency Tracking">Section 5.15</a>).
 212   </p><p>
 213    <code class="command">ALTER TABLE</code> will
 214    propagate any changes in column data definitions and check
 215    constraints down the inheritance hierarchy.  Again, dropping
 216    columns that are depended on by other tables is only possible when using
 217    the <code class="literal">CASCADE</code> option. <code class="command">ALTER
 218    TABLE</code> follows the same rules for duplicate column merging
 219    and rejection that apply during <code class="command">CREATE TABLE</code>.
 220   </p><p>
 221    Inherited queries perform access permission checks on the parent table
 222    only.  Thus, for example, granting <code class="literal">UPDATE</code> permission on
 223    the <code class="structname">cities</code> table implies permission to update rows in
 224    the <code class="structname">capitals</code> table as well, when they are
 225    accessed through <code class="structname">cities</code>.  This preserves the appearance
 226    that the data is (also) in the parent table.  But
 227    the <code class="structname">capitals</code> table could not be updated directly
 228    without an additional grant.  In a similar way, the parent table's row
 229    security policies (see <a class="xref" href="ddl-rowsecurity.html" title="5.9. Row Security Policies">Section 5.9</a>) are applied to
 230    rows coming from child tables during an inherited query.  A child table's
 231    policies, if any, are applied only when it is the table explicitly named
 232    in the query; and in that case, any policies attached to its parent(s) are
 233    ignored.
 234   </p><p>
 235    Foreign tables (see <a class="xref" href="ddl-foreign-data.html" title="5.13. Foreign Data">Section 5.13</a>) can also
 236    be part of inheritance hierarchies, either as parent or child
 237    tables, just as regular tables can be.  If a foreign table is part
 238    of an inheritance hierarchy then any operations not supported by
 239    the foreign table are not supported on the whole hierarchy either.
 240   </p><div class="sect2" id="DDL-INHERIT-CAVEATS"><div class="titlepage"><div><div><h3 class="title">5.11.1. Caveats <a href="#DDL-INHERIT-CAVEATS" class="id_link">#</a></h3></div></div></div><p>
 241    Note that not all SQL commands are able to work on
 242    inheritance hierarchies.  Commands that are used for data querying,
 243    data modification, or schema modification
 244    (e.g., <code class="literal">SELECT</code>, <code class="literal">UPDATE</code>, <code class="literal">DELETE</code>,
 245    most variants of <code class="literal">ALTER TABLE</code>, but
 246    not <code class="literal">INSERT</code> or <code class="literal">ALTER TABLE ...
 247    RENAME</code>) typically default to including child tables and
 248    support the <code class="literal">ONLY</code> notation to exclude them.
 249    The majority of commands that do database maintenance and tuning
 250    (e.g., <code class="literal">REINDEX</code>) only work on individual, physical
 251    tables and do not support recursing over inheritance hierarchies.
 252    However, both <code class="literal">VACUUM</code> and <code class="literal">ANALYZE</code>
 253    commands default to including child tables and the <code class="literal">ONLY</code>
 254    notation is supported to allow them to be excluded.  The respective
 255    behavior of each individual command is documented in its reference page
 256    (<a class="xref" href="sql-commands.html" title="SQL Commands">SQL Commands</a>).
 257   </p><p>
 258    A serious limitation of the inheritance feature is that indexes (including
 259    unique constraints) and foreign key constraints only apply to single
 260    tables, not to their inheritance children. This is true on both the
 261    referencing and referenced sides of a foreign key constraint. Thus,
 262    in the terms of the above example:
 263
 264    </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
 265       If we declared <code class="structname">cities</code>.<code class="structfield">name</code> to be
 266       <code class="literal">UNIQUE</code> or a <code class="literal">PRIMARY KEY</code>, this would not stop the
 267       <code class="structname">capitals</code> table from having rows with names duplicating
 268       rows in <code class="structname">cities</code>.  And those duplicate rows would by
 269       default show up in queries from <code class="structname">cities</code>.  In fact, by
 270       default <code class="structname">capitals</code> would have no unique constraint at all,
 271       and so could contain multiple rows with the same name.
 272       You could add a unique constraint to <code class="structname">capitals</code>, but this
 273       would not prevent duplication compared to <code class="structname">cities</code>.
 274      </p></li><li class="listitem"><p>
 275       Similarly, if we were to specify that
 276       <code class="structname">cities</code>.<code class="structfield">name</code> <code class="literal">REFERENCES</code> some
 277       other table, this constraint would not automatically propagate to
 278       <code class="structname">capitals</code>.  In this case you could work around it by
 279       manually adding the same <code class="literal">REFERENCES</code> constraint to
 280       <code class="structname">capitals</code>.
 281      </p></li><li class="listitem"><p>
 282       Specifying that another table's column <code class="literal">REFERENCES
 283       cities(name)</code> would allow the other table to contain city names, but
 284       not capital names.  There is no good workaround for this case.
 285      </p></li></ul></div><p>
 286
 287    Some functionality not implemented for inheritance hierarchies is
 288    implemented for declarative partitioning.
 289    Considerable care is needed in deciding whether partitioning with legacy
 290    inheritance is useful for your application.
 291   </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ddl-schemas.html" title="5.10. Schemas">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ddl.html" title="Chapter 5. Data Definition">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ddl-partitioning.html" title="5.12. Table Partitioning">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.10. Schemas </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 5.12. Table Partitioning</td></tr></table></div></body></html>