1
<!-- doc/src/sgml/ddl.sgml -->
4
<title>Data Definition</title>
7
This chapter covers how one creates the database structures that
8
will hold one's data. In a relational database, the raw data is
9
stored in tables, so the majority of this chapter is devoted to
10
explaining how tables are created and modified and what features are
11
available to control what data is stored in the tables.
12
Subsequently, we discuss how tables can be organized into
13
schemas, and how privileges can be assigned to tables. Finally,
14
we will briefly look at other features that affect the data storage,
15
such as inheritance, views, functions, and triggers.
18
<sect1 id="ddl-basics">
19
<title>Table Basics</title>
21
<indexterm zone="ddl-basics">
22
<primary>table</primary>
26
<primary>row</primary>
30
<primary>column</primary>
34
A table in a relational database is much like a table on paper: It
35
consists of rows and columns. The number and order of the columns
36
is fixed, and each column has a name. The number of rows is
37
variable — it reflects how much data is stored at a given moment.
38
SQL does not make any guarantees about the order of the rows in a
39
table. When a table is read, the rows will appear in an unspecified order,
40
unless sorting is explicitly requested. This is covered in <xref
41
linkend="queries">. Furthermore, SQL does not assign unique
42
identifiers to rows, so it is possible to have several completely
43
identical rows in a table. This is a consequence of the
44
mathematical model that underlies SQL but is usually not desirable.
45
Later in this chapter we will see how to deal with this issue.
49
Each column has a data type. The data type constrains the set of
50
possible values that can be assigned to a column and assigns
51
semantics to the data stored in the column so that it can be used
52
for computations. For instance, a column declared to be of a
53
numerical type will not accept arbitrary text strings, and the data
54
stored in such a column can be used for mathematical computations.
55
By contrast, a column declared to be of a character string type
56
will accept almost any kind of data but it does not lend itself to
57
mathematical calculations, although other operations such as string
58
concatenation are available.
62
<productname>PostgreSQL</productname> includes a sizable set of
63
built-in data types that fit many applications. Users can also
64
define their own data types. Most built-in data types have obvious
65
names and semantics, so we defer a detailed explanation to <xref
66
linkend="datatype">. Some of the frequently used data types are
67
<type>integer</type> for whole numbers, <type>numeric</type> for
68
possibly fractional numbers, <type>text</type> for character
69
strings, <type>date</type> for dates, <type>time</type> for
70
time-of-day values, and <type>timestamp</type> for values
71
containing both date and time.
75
<primary>table</primary>
76
<secondary>creating</secondary>
80
To create a table, you use the aptly named <xref
81
linkend="sql-createtable"> command.
82
In this command you specify at least a name for the new table, the
83
names of the columns and the data type of each column. For
86
CREATE TABLE my_first_table (
91
This creates a table named <literal>my_first_table</literal> with
92
two columns. The first column is named
93
<literal>first_column</literal> and has a data type of
94
<type>text</type>; the second column has the name
95
<literal>second_column</literal> and the type <type>integer</type>.
96
The table and column names follow the identifier syntax explained
97
in <xref linkend="sql-syntax-identifiers">. The type names are
98
usually also identifiers, but there are some exceptions. Note that the
99
column list is comma-separated and surrounded by parentheses.
103
Of course, the previous example was heavily contrived. Normally,
104
you would give names to your tables and columns that convey what
105
kind of data they store. So let's look at a more realistic
108
CREATE TABLE products (
114
(The <type>numeric</type> type can store fractional components, as
115
would be typical of monetary amounts.)
120
When you create many interrelated tables it is wise to choose a
121
consistent naming pattern for the tables and columns. For
122
instance, there is a choice of using singular or plural nouns for
123
table names, both of which are favored by some theorist or other.
128
There is a limit on how many columns a table can contain.
129
Depending on the column types, it is between 250 and 1600.
130
However, defining a table with anywhere near this many columns is
131
highly unusual and often a questionable design.
135
<primary>table</primary>
136
<secondary>removing</secondary>
140
If you no longer need a table, you can remove it using the <xref
141
linkend="sql-droptable"> command.
144
DROP TABLE my_first_table;
147
Attempting to drop a table that does not exist is an error.
148
Nevertheless, it is common in SQL script files to unconditionally
149
try to drop each table before creating it, ignoring any error
150
messages, so that the script works whether or not the table exists.
151
(If you like, you can use the <literal>DROP TABLE IF EXISTS</> variant
152
to avoid the error messages, but this is not standard SQL.)
156
If you need to modify a table that already exists, see <xref
157
linkend="ddl-alter"> later in this chapter.
161
With the tools discussed so far you can create fully functional
162
tables. The remainder of this chapter is concerned with adding
163
features to the table definition to ensure data integrity,
164
security, or convenience. If you are eager to fill your tables with
165
data now you can skip ahead to <xref linkend="dml"> and read the
166
rest of this chapter later.
170
<sect1 id="ddl-default">
171
<title>Default Values</title>
173
<indexterm zone="ddl-default">
174
<primary>default value</primary>
178
A column can be assigned a default value. When a new row is
179
created and no values are specified for some of the columns, those
180
columns will be filled with their respective default values. A
181
data manipulation command can also request explicitly that a column
182
be set to its default value, without having to know what that value is.
183
(Details about data manipulation commands are in <xref linkend="dml">.)
187
<indexterm><primary>null value</primary><secondary>default value</secondary></indexterm>
188
If no default value is declared explicitly, the default value is the
189
null value. This usually makes sense because a null value can
190
be considered to represent unknown data.
194
In a table definition, default values are listed after the column
195
data type. For example:
197
CREATE TABLE products (
200
price numeric <emphasis>DEFAULT 9.99</emphasis>
206
The default value can be an expression, which will be
207
evaluated whenever the default value is inserted
208
(<emphasis>not</emphasis> when the table is created). A common example
209
is for a <type>timestamp</type> column to have a default of <literal>CURRENT_TIMESTAMP</>,
210
so that it gets set to the time of row insertion. Another common
211
example is generating a <quote>serial number</> for each row.
212
In <productname>PostgreSQL</productname> this is typically done by
215
CREATE TABLE products (
216
product_no integer <emphasis>DEFAULT nextval('products_product_no_seq')</emphasis>,
220
where the <literal>nextval()</> function supplies successive values
221
from a <firstterm>sequence object</> (see <xref
222
linkend="functions-sequence">). This arrangement is sufficiently common
223
that there's a special shorthand for it:
225
CREATE TABLE products (
226
product_no <emphasis>SERIAL</emphasis>,
230
The <literal>SERIAL</> shorthand is discussed further in <xref
231
linkend="datatype-serial">.
235
<sect1 id="ddl-constraints">
236
<title>Constraints</title>
238
<indexterm zone="ddl-constraints">
239
<primary>constraint</primary>
243
Data types are a way to limit the kind of data that can be stored
244
in a table. For many applications, however, the constraint they
245
provide is too coarse. For example, a column containing a product
246
price should probably only accept positive values. But there is no
247
standard data type that accepts only positive numbers. Another issue is
248
that you might want to constrain column data with respect to other
249
columns or rows. For example, in a table containing product
250
information, there should be only one row for each product number.
254
To that end, SQL allows you to define constraints on columns and
255
tables. Constraints give you as much control over the data in your
256
tables as you wish. If a user attempts to store data in a column
257
that would violate a constraint, an error is raised. This applies
258
even if the value came from the default value definition.
262
<title>Check Constraints</title>
265
<primary>check constraint</primary>
269
<primary>constraint</primary>
270
<secondary>check</secondary>
274
A check constraint is the most generic constraint type. It allows
275
you to specify that the value in a certain column must satisfy a
276
Boolean (truth-value) expression. For instance, to require positive
277
product prices, you could use:
279
CREATE TABLE products (
282
price numeric <emphasis>CHECK (price > 0)</emphasis>
288
As you see, the constraint definition comes after the data type,
289
just like default value definitions. Default values and
290
constraints can be listed in any order. A check constraint
291
consists of the key word <literal>CHECK</literal> followed by an
292
expression in parentheses. The check constraint expression should
293
involve the column thus constrained, otherwise the constraint
294
would not make too much sense.
298
<primary>constraint</primary>
299
<secondary>name</secondary>
303
You can also give the constraint a separate name. This clarifies
304
error messages and allows you to refer to the constraint when you
305
need to change it. The syntax is:
307
CREATE TABLE products (
310
price numeric <emphasis>CONSTRAINT positive_price</emphasis> CHECK (price > 0)
313
So, to specify a named constraint, use the key word
314
<literal>CONSTRAINT</literal> followed by an identifier followed
315
by the constraint definition. (If you don't specify a constraint
316
name in this way, the system chooses a name for you.)
320
A check constraint can also refer to several columns. Say you
321
store a regular price and a discounted price, and you want to
322
ensure that the discounted price is lower than the regular price:
324
CREATE TABLE products (
327
price numeric CHECK (price > 0),
328
discounted_price numeric CHECK (discounted_price > 0),
329
<emphasis>CHECK (price > discounted_price)</emphasis>
335
The first two constraints should look familiar. The third one
336
uses a new syntax. It is not attached to a particular column,
337
instead it appears as a separate item in the comma-separated
338
column list. Column definitions and these constraint
339
definitions can be listed in mixed order.
343
We say that the first two constraints are column constraints, whereas the
344
third one is a table constraint because it is written separately
345
from any one column definition. Column constraints can also be
346
written as table constraints, while the reverse is not necessarily
347
possible, since a column constraint is supposed to refer to only the
348
column it is attached to. (<productname>PostgreSQL</productname> doesn't
349
enforce that rule, but you should follow it if you want your table
350
definitions to work with other database systems.) The above example could
353
CREATE TABLE products (
357
CHECK (price > 0),
358
discounted_price numeric,
359
CHECK (discounted_price > 0),
360
CHECK (price > discounted_price)
365
CREATE TABLE products (
368
price numeric CHECK (price > 0),
369
discounted_price numeric,
370
CHECK (discounted_price > 0 AND price > discounted_price)
373
It's a matter of taste.
377
Names can be assigned to table constraints in the same way as
380
CREATE TABLE products (
384
CHECK (price > 0),
385
discounted_price numeric,
386
CHECK (discounted_price > 0),
387
<emphasis>CONSTRAINT valid_discount</> CHECK (price > discounted_price)
393
<primary>null value</primary>
394
<secondary sortas="check constraints">with check constraints</secondary>
398
It should be noted that a check constraint is satisfied if the
399
check expression evaluates to true or the null value. Since most
400
expressions will evaluate to the null value if any operand is null,
401
they will not prevent null values in the constrained columns. To
402
ensure that a column does not contain null values, the not-null
403
constraint described in the next section can be used.
408
<title>Not-Null Constraints</title>
411
<primary>not-null constraint</primary>
415
<primary>constraint</primary>
416
<secondary>NOT NULL</secondary>
420
A not-null constraint simply specifies that a column must not
421
assume the null value. A syntax example:
423
CREATE TABLE products (
424
product_no integer <emphasis>NOT NULL</emphasis>,
425
name text <emphasis>NOT NULL</emphasis>,
432
A not-null constraint is always written as a column constraint. A
433
not-null constraint is functionally equivalent to creating a check
434
constraint <literal>CHECK (<replaceable>column_name</replaceable>
435
IS NOT NULL)</literal>, but in
436
<productname>PostgreSQL</productname> creating an explicit
437
not-null constraint is more efficient. The drawback is that you
438
cannot give explicit names to not-null constraints created this
443
Of course, a column can have more than one constraint. Just write
444
the constraints one after another:
446
CREATE TABLE products (
447
product_no integer NOT NULL,
449
price numeric NOT NULL CHECK (price > 0)
452
The order doesn't matter. It does not necessarily determine in which
453
order the constraints are checked.
457
The <literal>NOT NULL</literal> constraint has an inverse: the
458
<literal>NULL</literal> constraint. This does not mean that the
459
column must be null, which would surely be useless. Instead, this
460
simply selects the default behavior that the column might be null.
461
The <literal>NULL</literal> constraint is not present in the SQL
462
standard and should not be used in portable applications. (It was
463
only added to <productname>PostgreSQL</productname> to be
464
compatible with some other database systems.) Some users, however,
465
like it because it makes it easy to toggle the constraint in a
466
script file. For example, you could start with:
468
CREATE TABLE products (
469
product_no integer NULL,
474
and then insert the <literal>NOT</literal> key word where desired.
479
In most database designs the majority of columns should be marked
486
<title>Unique Constraints</title>
489
<primary>unique constraint</primary>
493
<primary>constraint</primary>
494
<secondary>unique</secondary>
498
Unique constraints ensure that the data contained in a column or a
499
group of columns is unique with respect to all the rows in the
500
table. The syntax is:
502
CREATE TABLE products (
503
product_no integer <emphasis>UNIQUE</emphasis>,
508
when written as a column constraint, and:
510
CREATE TABLE products (
514
<emphasis>UNIQUE (product_no)</emphasis>
517
when written as a table constraint.
521
If a unique constraint refers to a group of columns, the columns
522
are listed separated by commas:
524
CREATE TABLE example (
528
<emphasis>UNIQUE (a, c)</emphasis>
531
This specifies that the combination of values in the indicated columns
532
is unique across the whole table, though any one of the columns
533
need not be (and ordinarily isn't) unique.
537
You can assign your own name for a unique constraint, in the usual way:
539
CREATE TABLE products (
540
product_no integer <emphasis>CONSTRAINT must_be_different</emphasis> UNIQUE,
548
Adding a unique constraint will automatically create a unique btree
549
index on the column or group of columns used in the constraint.
553
<primary>null value</primary>
554
<secondary sortas="unique constraints">with unique constraints</secondary>
558
In general, a unique constraint is violated when there is more than
559
one row in the table where the values of all of the
560
columns included in the constraint are equal.
561
However, two null values are not considered equal in this
562
comparison. That means even in the presence of a
563
unique constraint it is possible to store duplicate
564
rows that contain a null value in at least one of the constrained
565
columns. This behavior conforms to the SQL standard, but we have
566
heard that other SQL databases might not follow this rule. So be
567
careful when developing applications that are intended to be
573
<title>Primary Keys</title>
576
<primary>primary key</primary>
580
<primary>constraint</primary>
581
<secondary>primary key</secondary>
585
Technically, a primary key constraint is simply a combination of a
586
unique constraint and a not-null constraint. So, the following
587
two table definitions accept the same data:
589
CREATE TABLE products (
590
product_no integer UNIQUE NOT NULL,
597
CREATE TABLE products (
598
product_no integer <emphasis>PRIMARY KEY</emphasis>,
606
Primary keys can also constrain more than one column; the syntax
607
is similar to unique constraints:
609
CREATE TABLE example (
613
<emphasis>PRIMARY KEY (a, c)</emphasis>
619
A primary key indicates that a column or group of columns can be
620
used as a unique identifier for rows in the table. (This is a
621
direct consequence of the definition of a primary key. Note that
622
a unique constraint does not, by itself, provide a unique identifier
623
because it does not exclude null values.) This is useful both for
624
documentation purposes and for client applications. For example,
625
a GUI application that allows modifying row values probably needs
626
to know the primary key of a table to be able to identify rows
631
Adding a primary key will automatically create a unique btree index
632
on the column or group of columns used in the primary key.
636
A table can have at most one primary key. (There can be any number
637
of unique and not-null constraints, which are functionally the same
638
thing, but only one can be identified as the primary key.)
639
Relational database theory
640
dictates that every table must have a primary key. This rule is
641
not enforced by <productname>PostgreSQL</productname>, but it is
642
usually best to follow it.
646
<sect2 id="ddl-constraints-fk">
647
<title>Foreign Keys</title>
650
<primary>foreign key</primary>
654
<primary>constraint</primary>
655
<secondary>foreign key</secondary>
659
<primary>referential integrity</primary>
663
A foreign key constraint specifies that the values in a column (or
664
a group of columns) must match the values appearing in some row
666
We say this maintains the <firstterm>referential
667
integrity</firstterm> between two related tables.
671
Say you have the product table that we have used several times already:
673
CREATE TABLE products (
674
product_no integer PRIMARY KEY,
679
Let's also assume you have a table storing orders of those
680
products. We want to ensure that the orders table only contains
681
orders of products that actually exist. So we define a foreign
682
key constraint in the orders table that references the products
685
CREATE TABLE orders (
686
order_id integer PRIMARY KEY,
687
product_no integer <emphasis>REFERENCES products (product_no)</emphasis>,
691
Now it is impossible to create orders with
692
<structfield>product_no</structfield> entries that do not appear in the
697
We say that in this situation the orders table is the
698
<firstterm>referencing</firstterm> table and the products table is
699
the <firstterm>referenced</firstterm> table. Similarly, there are
700
referencing and referenced columns.
704
You can also shorten the above command to:
706
CREATE TABLE orders (
707
order_id integer PRIMARY KEY,
708
product_no integer <emphasis>REFERENCES products</emphasis>,
712
because in absence of a column list the primary key of the
713
referenced table is used as the referenced column(s).
717
A foreign key can also constrain and reference a group of columns.
718
As usual, it then needs to be written in table constraint form.
719
Here is a contrived syntax example:
722
a integer PRIMARY KEY,
725
<emphasis>FOREIGN KEY (b, c) REFERENCES other_table (c1, c2)</emphasis>
728
Of course, the number and type of the constrained columns need to
729
match the number and type of the referenced columns.
733
You can assign your own name for a foreign key constraint,
738
A table can contain more than one foreign key constraint. This is
739
used to implement many-to-many relationships between tables. Say
740
you have tables about products and orders, but now you want to
741
allow one order to contain possibly many products (which the
742
structure above did not allow). You could use this table structure:
744
CREATE TABLE products (
745
product_no integer PRIMARY KEY,
750
CREATE TABLE orders (
751
order_id integer PRIMARY KEY,
752
shipping_address text,
756
CREATE TABLE order_items (
757
product_no integer REFERENCES products,
758
order_id integer REFERENCES orders,
760
PRIMARY KEY (product_no, order_id)
763
Notice that the primary key overlaps with the foreign keys in
768
<primary>CASCADE</primary>
769
<secondary>foreign key action</secondary>
773
<primary>RESTRICT</primary>
774
<secondary>foreign key action</secondary>
778
We know that the foreign keys disallow creation of orders that
779
do not relate to any products. But what if a product is removed
780
after an order is created that references it? SQL allows you to
781
handle that as well. Intuitively, we have a few options:
782
<itemizedlist spacing="compact">
783
<listitem><para>Disallow deleting a referenced product</para></listitem>
784
<listitem><para>Delete the orders as well</para></listitem>
785
<listitem><para>Something else?</para></listitem>
790
To illustrate this, let's implement the following policy on the
791
many-to-many relationship example above: when someone wants to
792
remove a product that is still referenced by an order (via
793
<literal>order_items</literal>), we disallow it. If someone
794
removes an order, the order items are removed as well:
796
CREATE TABLE products (
797
product_no integer PRIMARY KEY,
802
CREATE TABLE orders (
803
order_id integer PRIMARY KEY,
804
shipping_address text,
808
CREATE TABLE order_items (
809
product_no integer REFERENCES products <emphasis>ON DELETE RESTRICT</emphasis>,
810
order_id integer REFERENCES orders <emphasis>ON DELETE CASCADE</emphasis>,
812
PRIMARY KEY (product_no, order_id)
818
Restricting and cascading deletes are the two most common options.
819
<literal>RESTRICT</literal> prevents deletion of a
820
referenced row. <literal>NO ACTION</literal> means that if any
821
referencing rows still exist when the constraint is checked, an error
822
is raised; this is the default behavior if you do not specify anything.
823
(The essential difference between these two choices is that
824
<literal>NO ACTION</literal> allows the check to be deferred until
825
later in the transaction, whereas <literal>RESTRICT</literal> does not.)
826
<literal>CASCADE</> specifies that when a referenced row is deleted,
827
row(s) referencing it should be automatically deleted as well.
828
There are two other options:
829
<literal>SET NULL</literal> and <literal>SET DEFAULT</literal>.
830
These cause the referencing columns to be set to nulls or default
831
values, respectively, when the referenced row is deleted.
832
Note that these do not excuse you from observing any constraints.
833
For example, if an action specifies <literal>SET DEFAULT</literal>
834
but the default value would not satisfy the foreign key, the
839
Analogous to <literal>ON DELETE</literal> there is also
840
<literal>ON UPDATE</literal> which is invoked when a referenced
841
column is changed (updated). The possible actions are the same.
845
Since a <command>DELETE</command> of a row from the referenced table
846
or an <command>UPDATE</command> of a referenced column will require
847
a scan of the referencing table for rows matching the old value, it
848
is often a good idea to index the referencing columns. Because this
849
is not always needed, and there are many choices available on how
850
to index, declaration of a foreign key constraint does not
851
automatically create an index on the referencing columns.
855
More information about updating and deleting data is in <xref
860
Finally, we should mention that a foreign key must reference
861
columns that either are a primary key or form a unique constraint.
862
If the foreign key references a unique constraint, there are some
863
additional possibilities regarding how null values are matched.
864
These are explained in the reference documentation for
865
<xref linkend="sql-createtable">.
869
<sect2 id="ddl-constraints-exclusion">
870
<title>Exclusion Constraints</title>
873
<primary>exclusion constraint</primary>
877
<primary>constraint</primary>
878
<secondary>exclusion</secondary>
882
Exclusion constraints ensure that if any two rows are compared on
883
the specified columns or expressions using the specified operators,
884
at least one of these operator comparisons will return false or null.
887
CREATE TABLE circles (
889
EXCLUDE USING gist (c WITH &&)
895
See also <link linkend="SQL-CREATETABLE-EXCLUDE"><command>CREATE
896
TABLE ... CONSTRAINT ... EXCLUDE</></link> for details.
900
Adding an exclusion constraint will automatically create an index
901
of the type specified in the constraint declaration.
906
<sect1 id="ddl-system-columns">
907
<title>System Columns</title>
910
Every table has several <firstterm>system columns</> that are
911
implicitly defined by the system. Therefore, these names cannot be
912
used as names of user-defined columns. (Note that these
913
restrictions are separate from whether the name is a key word or
914
not; quoting a name will not allow you to escape these
915
restrictions.) You do not really need to be concerned about these
916
columns; just know they exist.
920
<primary>column</primary>
921
<secondary>system column</secondary>
926
<term><structfield>oid</></term>
930
<primary>OID</primary>
931
<secondary>column</secondary>
933
The object identifier (object ID) of a row. This column is only
934
present if the table was created using <literal>WITH
935
OIDS</literal>, or if the <xref linkend="guc-default-with-oids">
936
configuration variable was set at the time. This column is of type
937
<type>oid</type> (same name as the column); see <xref
938
linkend="datatype-oid"> for more information about the type.
944
<term><structfield>tableoid</></term>
947
<primary>tableoid</primary>
951
The OID of the table containing this row. This column is
952
particularly handy for queries that select from inheritance
953
hierarchies (see <xref linkend="ddl-inherit">), since without it,
954
it's difficult to tell which individual table a row came from. The
955
<structfield>tableoid</structfield> can be joined against the
956
<structfield>oid</structfield> column of
957
<structname>pg_class</structname> to obtain the table name.
963
<term><structfield>xmin</></term>
966
<primary>xmin</primary>
970
The identity (transaction ID) of the inserting transaction for
971
this row version. (A row version is an individual state of a
972
row; each update of a row creates a new row version for the same
979
<term><structfield>cmin</></term>
982
<primary>cmin</primary>
986
The command identifier (starting at zero) within the inserting
993
<term><structfield>xmax</></term>
996
<primary>xmax</primary>
1000
The identity (transaction ID) of the deleting transaction, or
1001
zero for an undeleted row version. It is possible for this column to
1002
be nonzero in a visible row version. That usually indicates that the
1003
deleting transaction hasn't committed yet, or that an attempted
1004
deletion was rolled back.
1010
<term><structfield>cmax</></term>
1013
<primary>cmax</primary>
1017
The command identifier within the deleting transaction, or zero.
1023
<term><structfield>ctid</></term>
1026
<primary>ctid</primary>
1030
The physical location of the row version within its table. Note that
1031
although the <structfield>ctid</structfield> can be used to
1032
locate the row version very quickly, a row's
1033
<structfield>ctid</structfield> will change if it is
1034
updated or moved by <command>VACUUM FULL</>. Therefore
1035
<structfield>ctid</structfield> is useless as a long-term row
1036
identifier. The OID, or even better a user-defined serial
1037
number, should be used to identify logical rows.
1044
OIDs are 32-bit quantities and are assigned from a single
1045
cluster-wide counter. In a large or long-lived database, it is
1046
possible for the counter to wrap around. Hence, it is bad
1047
practice to assume that OIDs are unique, unless you take steps to
1048
ensure that this is the case. If you need to identify the rows in
1049
a table, using a sequence generator is strongly recommended.
1050
However, OIDs can be used as well, provided that a few additional
1051
precautions are taken:
1056
A unique constraint should be created on the OID column of each
1057
table for which the OID will be used to identify rows. When such
1058
a unique constraint (or unique index) exists, the system takes
1059
care not to generate an OID matching an already-existing row.
1060
(Of course, this is only possible if the table contains fewer
1061
than 2<superscript>32</> (4 billion) rows, and in practice the
1062
table size had better be much less than that, or performance
1068
OIDs should never be assumed to be unique across tables; use
1069
the combination of <structfield>tableoid</> and row OID if you
1070
need a database-wide identifier.
1075
Of course, the tables in question must be created <literal>WITH
1076
OIDS</literal>. As of <productname>PostgreSQL</productname> 8.1,
1077
<literal>WITHOUT OIDS</> is the default.
1084
Transaction identifiers are also 32-bit quantities. In a
1085
long-lived database it is possible for transaction IDs to wrap
1086
around. This is not a fatal problem given appropriate maintenance
1087
procedures; see <xref linkend="maintenance"> for details. It is
1088
unwise, however, to depend on the uniqueness of transaction IDs
1089
over the long term (more than one billion transactions).
1093
Command identifiers are also 32-bit quantities. This creates a hard limit
1094
of 2<superscript>32</> (4 billion) <acronym>SQL</acronym> commands
1095
within a single transaction. In practice this limit is not a
1096
problem — note that the limit is on the number of
1097
<acronym>SQL</acronym> commands, not the number of rows processed.
1098
Also, as of <productname>PostgreSQL</productname> 8.3, only commands
1099
that actually modify the database contents will consume a command
1104
<sect1 id="ddl-alter">
1105
<title>Modifying Tables</title>
1107
<indexterm zone="ddl-alter">
1108
<primary>table</primary>
1109
<secondary>modifying</secondary>
1113
When you create a table and you realize that you made a mistake, or
1114
the requirements of the application change, you can drop the
1115
table and create it again. But this is not a convenient option if
1116
the table is already filled with data, or if the table is
1117
referenced by other database objects (for instance a foreign key
1118
constraint). Therefore <productname>PostgreSQL</productname>
1119
provides a family of commands to make modifications to existing
1120
tables. Note that this is conceptually distinct from altering
1121
the data contained in the table: here we are interested in altering
1122
the definition, or structure, of the table.
1127
<itemizedlist spacing="compact">
1129
<para>Add columns</para>
1132
<para>Remove columns</para>
1135
<para>Add constraints</para>
1138
<para>Remove constraints</para>
1141
<para>Change default values</para>
1144
<para>Change column data types</para>
1147
<para>Rename columns</para>
1150
<para>Rename tables</para>
1154
All these actions are performed using the
1155
<xref linkend="sql-altertable">
1156
command, whose reference page contains details beyond those given
1161
<title>Adding a Column</title>
1164
<primary>column</primary>
1165
<secondary>adding</secondary>
1169
To add a column, use a command like:
1171
ALTER TABLE products ADD COLUMN description text;
1173
The new column is initially filled with whatever default
1174
value is given (null if you don't specify a <literal>DEFAULT</> clause).
1178
You can also define constraints on the column at the same time,
1179
using the usual syntax:
1181
ALTER TABLE products ADD COLUMN description text CHECK (description <> '');
1183
In fact all the options that can be applied to a column description
1184
in <command>CREATE TABLE</> can be used here. Keep in mind however
1185
that the default value must satisfy the given constraints, or the
1186
<literal>ADD</> will fail. Alternatively, you can add
1187
constraints later (see below) after you've filled in the new column
1193
Adding a column with a default requires updating each row of the
1194
table (to store the new column value). However, if no default is
1195
specified, <productname>PostgreSQL</productname> is able to avoid
1196
the physical update. So if you intend to fill the column with
1197
mostly nondefault values, it's best to add the column with no default,
1198
insert the correct values using <command>UPDATE</>, and then add any
1199
desired default as described below.
1205
<title>Removing a Column</title>
1208
<primary>column</primary>
1209
<secondary>removing</secondary>
1213
To remove a column, use a command like:
1215
ALTER TABLE products DROP COLUMN description;
1217
Whatever data was in the column disappears. Table constraints involving
1218
the column are dropped, too. However, if the column is referenced by a
1219
foreign key constraint of another table,
1220
<productname>PostgreSQL</productname> will not silently drop that
1221
constraint. You can authorize dropping everything that depends on
1222
the column by adding <literal>CASCADE</>:
1224
ALTER TABLE products DROP COLUMN description CASCADE;
1226
See <xref linkend="ddl-depend"> for a description of the general
1227
mechanism behind this.
1232
<title>Adding a Constraint</title>
1235
<primary>constraint</primary>
1236
<secondary>adding</secondary>
1240
To add a constraint, the table constraint syntax is used. For example:
1242
ALTER TABLE products ADD CHECK (name <> '');
1243
ALTER TABLE products ADD CONSTRAINT some_name UNIQUE (product_no);
1244
ALTER TABLE products ADD FOREIGN KEY (product_group_id) REFERENCES product_groups;
1246
To add a not-null constraint, which cannot be written as a table
1247
constraint, use this syntax:
1249
ALTER TABLE products ALTER COLUMN product_no SET NOT NULL;
1254
The constraint will be checked immediately, so the table data must
1255
satisfy the constraint before it can be added.
1260
<title>Removing a Constraint</title>
1263
<primary>constraint</primary>
1264
<secondary>removing</secondary>
1268
To remove a constraint you need to know its name. If you gave it
1269
a name then that's easy. Otherwise the system assigned a
1270
generated name, which you need to find out. The
1271
<application>psql</application> command <literal>\d
1272
<replaceable>tablename</replaceable></literal> can be helpful
1273
here; other interfaces might also provide a way to inspect table
1274
details. Then the command is:
1276
ALTER TABLE products DROP CONSTRAINT some_name;
1278
(If you are dealing with a generated constraint name like <literal>$2</>,
1279
don't forget that you'll need to double-quote it to make it a valid
1284
As with dropping a column, you need to add <literal>CASCADE</> if you
1285
want to drop a constraint that something else depends on. An example
1286
is that a foreign key constraint depends on a unique or primary key
1287
constraint on the referenced column(s).
1291
This works the same for all constraint types except not-null
1292
constraints. To drop a not null constraint use:
1294
ALTER TABLE products ALTER COLUMN product_no DROP NOT NULL;
1296
(Recall that not-null constraints do not have names.)
1301
<title>Changing a Column's Default Value</title>
1304
<primary>default value</primary>
1305
<secondary>changing</secondary>
1309
To set a new default for a column, use a command like:
1311
ALTER TABLE products ALTER COLUMN price SET DEFAULT 7.77;
1313
Note that this doesn't affect any existing rows in the table, it
1314
just changes the default for future <command>INSERT</> commands.
1318
To remove any default value, use:
1320
ALTER TABLE products ALTER COLUMN price DROP DEFAULT;
1322
This is effectively the same as setting the default to null.
1323
As a consequence, it is not an error
1324
to drop a default where one hadn't been defined, because the
1325
default is implicitly the null value.
1330
<title>Changing a Column's Data Type</title>
1333
<primary>column data type</primary>
1334
<secondary>changing</secondary>
1338
To convert a column to a different data type, use a command like:
1340
ALTER TABLE products ALTER COLUMN price TYPE numeric(10,2);
1342
This will succeed only if each existing entry in the column can be
1343
converted to the new type by an implicit cast. If a more complex
1344
conversion is needed, you can add a <literal>USING</> clause that
1345
specifies how to compute the new values from the old.
1349
<productname>PostgreSQL</> will attempt to convert the column's
1350
default value (if any) to the new type, as well as any constraints
1351
that involve the column. But these conversions might fail, or might
1352
produce surprising results. It's often best to drop any constraints
1353
on the column before altering its type, and then add back suitably
1354
modified constraints afterwards.
1359
<title>Renaming a Column</title>
1362
<primary>column</primary>
1363
<secondary>renaming</secondary>
1369
ALTER TABLE products RENAME COLUMN product_no TO product_number;
1375
<title>Renaming a Table</title>
1378
<primary>table</primary>
1379
<secondary>renaming</secondary>
1385
ALTER TABLE products RENAME TO items;
1391
<sect1 id="ddl-priv">
1392
<title>Privileges</title>
1394
<indexterm zone="ddl-priv">
1395
<primary>privilege</primary>
1399
<primary>permission</primary>
1400
<see>privilege</see>
1403
<indexterm zone="ddl-priv">
1404
<primary>owner</primary>
1407
<indexterm zone="ddl-priv">
1408
<primary>GRANT</primary>
1411
<indexterm zone="ddl-priv">
1412
<primary>REVOKE</primary>
1416
When an object is created, it is assigned an owner. The
1417
owner is normally the role that executed the creation statement.
1418
For most kinds of objects, the initial state is that only the owner
1419
(or a superuser) can do anything with the object. To allow
1420
other roles to use it, <firstterm>privileges</firstterm> must be
1422
There are several different kinds of privilege: <literal>SELECT</>,
1423
<literal>INSERT</>, <literal>UPDATE</>, <literal>DELETE</>,
1424
<literal>TRUNCATE</>, <literal>REFERENCES</>, <literal>TRIGGER</>,
1425
<literal>CREATE</>, <literal>CONNECT</>, <literal>TEMPORARY</>,
1426
<literal>EXECUTE</>, and <literal>USAGE</>.
1427
For more information on the different types of privileges supported by
1428
<productname>PostgreSQL</productname>, see the
1429
<xref linkend="sql-grant"> reference page.
1433
There are several different privileges: <literal>SELECT</>,
1434
<literal>INSERT</>, <literal>UPDATE</>, <literal>DELETE</>,
1435
<literal>TRUNCATE</>, <literal>REFERENCES</>, <literal>TRIGGER</>,
1436
<literal>CREATE</>, <literal>CONNECT</>, <literal>TEMPORARY</>,
1437
<literal>EXECUTE</>, and <literal>USAGE</>.
1438
The privileges applicable to a particular
1439
object vary depending on the object's type (table, function, etc).
1440
For complete information on the different types of privileges
1441
supported by <productname>PostgreSQL</productname>, refer to the
1442
<xref linkend="sql-grant"> reference
1443
page. The following sections and chapters will also show you how
1444
those privileges are used.
1448
The right to modify or destroy an object is always the privilege of
1453
An object can be assigned to a new owner with an <command>ALTER</command>
1454
command of the appropriate kind for the object, e.g. <xref
1455
linkend="sql-altertable">. Superusers can always do
1456
this; ordinary roles can only do it if they are both the current owner
1457
of the object (or a member of the owning role) and a member of the new
1462
To assign privileges, the <command>GRANT</command> command is
1463
used. For example, if <literal>joe</literal> is an existing user, and
1464
<literal>accounts</literal> is an existing table, the privilege to
1465
update the table can be granted with:
1467
GRANT UPDATE ON accounts TO joe;
1469
Writing <literal>ALL</literal> in place of a specific privilege grants all
1470
privileges that are relevant for the object type.
1474
The special <quote>user</quote> name <literal>PUBLIC</literal> can
1475
be used to grant a privilege to every user on the system. Also,
1476
<quote>group</> roles can be set up to help manage privileges when
1477
there are many users of a database — for details see
1478
<xref linkend="user-manag">.
1482
To revoke a privilege, use the fittingly named
1483
<command>REVOKE</command> command:
1485
REVOKE ALL ON accounts FROM PUBLIC;
1487
The special privileges of the object owner (i.e., the right to do
1488
<command>DROP</>, <command>GRANT</>, <command>REVOKE</>, etc.)
1489
are always implicit in being the owner,
1490
and cannot be granted or revoked. But the object owner can choose
1491
to revoke his own ordinary privileges, for example to make a
1492
table read-only for himself as well as others.
1496
Ordinarily, only the object's owner (or a superuser) can grant or
1497
revoke privileges on an object. However, it is possible to grant a
1498
privilege <quote>with grant option</>, which gives the recipient
1499
the right to grant it in turn to others. If the grant option is
1500
subsequently revoked then all who received the privilege from that
1501
recipient (directly or through a chain of grants) will lose the
1502
privilege. For details see the <xref linkend="sql-grant"> and
1503
<xref linkend="sql-revoke"> reference pages.
1507
<sect1 id="ddl-schemas">
1508
<title>Schemas</title>
1510
<indexterm zone="ddl-schemas">
1511
<primary>schema</primary>
1515
A <productname>PostgreSQL</productname> database cluster
1516
contains one or more named databases. Users and groups of users are
1517
shared across the entire cluster, but no other data is shared across
1518
databases. Any given client connection to the server can access
1519
only the data in a single database, the one specified in the connection
1525
Users of a cluster do not necessarily have the privilege to access every
1526
database in the cluster. Sharing of user names means that there
1527
cannot be different users named, say, <literal>joe</> in two databases
1528
in the same cluster; but the system can be configured to allow
1529
<literal>joe</> access to only some of the databases.
1534
A database contains one or more named <firstterm>schemas</>, which
1535
in turn contain tables. Schemas also contain other kinds of named
1536
objects, including data types, functions, and operators. The same
1537
object name can be used in different schemas without conflict; for
1538
example, both <literal>schema1</> and <literal>myschema</> can
1539
contain tables named <literal>mytable</>. Unlike databases,
1540
schemas are not rigidly separated: a user can access objects in any
1541
of the schemas in the database he is connected to, if he has
1542
privileges to do so.
1546
There are several reasons why one might want to use schemas:
1551
To allow many users to use one database without interfering with
1558
To organize database objects into logical groups to make them
1565
Third-party applications can be put into separate schemas so
1566
they do not collide with the names of other objects.
1571
Schemas are analogous to directories at the operating system level,
1572
except that schemas cannot be nested.
1575
<sect2 id="ddl-schemas-create">
1576
<title>Creating a Schema</title>
1578
<indexterm zone="ddl-schemas-create">
1579
<primary>schema</primary>
1580
<secondary>creating</secondary>
1584
To create a schema, use the <xref linkend="sql-createschema">
1585
command. Give the schema a name
1586
of your choice. For example:
1588
CREATE SCHEMA myschema;
1593
<primary>qualified name</primary>
1597
<primary>name</primary>
1598
<secondary>qualified</secondary>
1602
To create or access objects in a schema, write a
1603
<firstterm>qualified name</> consisting of the schema name and
1604
table name separated by a dot:
1606
<replaceable>schema</><literal>.</><replaceable>table</>
1608
This works anywhere a table name is expected, including the table
1609
modification commands and the data access commands discussed in
1610
the following chapters.
1611
(For brevity we will speak of tables only, but the same ideas apply
1612
to other kinds of named objects, such as types and functions.)
1616
Actually, the even more general syntax
1618
<replaceable>database</><literal>.</><replaceable>schema</><literal>.</><replaceable>table</>
1620
can be used too, but at present this is just for <foreignphrase>pro
1621
forma</> compliance with the SQL standard. If you write a database name,
1622
it must be the same as the database you are connected to.
1626
So to create a table in the new schema, use:
1628
CREATE TABLE myschema.mytable (
1635
<primary>schema</primary>
1636
<secondary>removing</secondary>
1640
To drop a schema if it's empty (all objects in it have been
1643
DROP SCHEMA myschema;
1645
To drop a schema including all contained objects, use:
1647
DROP SCHEMA myschema CASCADE;
1649
See <xref linkend="ddl-depend"> for a description of the general
1650
mechanism behind this.
1654
Often you will want to create a schema owned by someone else
1655
(since this is one of the ways to restrict the activities of your
1656
users to well-defined namespaces). The syntax for that is:
1658
CREATE SCHEMA <replaceable>schemaname</replaceable> AUTHORIZATION <replaceable>username</replaceable>;
1660
You can even omit the schema name, in which case the schema name
1661
will be the same as the user name. See <xref
1662
linkend="ddl-schemas-patterns"> for how this can be useful.
1666
Schema names beginning with <literal>pg_</> are reserved for
1667
system purposes and cannot be created by users.
1671
<sect2 id="ddl-schemas-public">
1672
<title>The Public Schema</title>
1674
<indexterm zone="ddl-schemas-public">
1675
<primary>schema</primary>
1676
<secondary>public</secondary>
1680
In the previous sections we created tables without specifying any
1681
schema names. By default such tables (and other objects) are
1682
automatically put into a schema named <quote>public</quote>. Every new
1683
database contains such a schema. Thus, the following are equivalent:
1685
CREATE TABLE products ( ... );
1689
CREATE TABLE public.products ( ... );
1694
<sect2 id="ddl-schemas-path">
1695
<title>The Schema Search Path</title>
1698
<primary>search path</primary>
1702
<primary>unqualified name</primary>
1706
<primary>name</primary>
1707
<secondary>unqualified</secondary>
1711
Qualified names are tedious to write, and it's often best not to
1712
wire a particular schema name into applications anyway. Therefore
1713
tables are often referred to by <firstterm>unqualified names</>,
1714
which consist of just the table name. The system determines which table
1715
is meant by following a <firstterm>search path</>, which is a list
1716
of schemas to look in. The first matching table in the search path
1717
is taken to be the one wanted. If there is no match in the search
1718
path, an error is reported, even if matching table names exist
1719
in other schemas in the database.
1723
<primary>schema</primary>
1724
<secondary>current</secondary>
1728
The first schema named in the search path is called the current schema.
1729
Aside from being the first schema searched, it is also the schema in
1730
which new tables will be created if the <command>CREATE TABLE</>
1731
command does not specify a schema name.
1735
<primary>search_path</primary>
1739
To show the current search path, use the following command:
1743
In the default setup this returns:
1749
The first element specifies that a schema with the same name as
1750
the current user is to be searched. If no such schema exists,
1751
the entry is ignored. The second element refers to the
1752
public schema that we have seen already.
1756
The first schema in the search path that exists is the default
1757
location for creating new objects. That is the reason that by
1758
default objects are created in the public schema. When objects
1759
are referenced in any other context without schema qualification
1760
(table modification, data modification, or query commands) the
1761
search path is traversed until a matching object is found.
1762
Therefore, in the default configuration, any unqualified access
1763
again can only refer to the public schema.
1767
To put our new schema in the path, we use:
1769
SET search_path TO myschema,public;
1771
(We omit the <literal>$user</literal> here because we have no
1772
immediate need for it.) And then we can access the table without
1773
schema qualification:
1777
Also, since <literal>myschema</literal> is the first element in
1778
the path, new objects would by default be created in it.
1782
We could also have written:
1784
SET search_path TO myschema;
1786
Then we no longer have access to the public schema without
1787
explicit qualification. There is nothing special about the public
1788
schema except that it exists by default. It can be dropped, too.
1792
See also <xref linkend="functions-info"> for other ways to manipulate
1793
the schema search path.
1797
The search path works in the same way for data type names, function names,
1798
and operator names as it does for table names. Data type and function
1799
names can be qualified in exactly the same way as table names. If you
1800
need to write a qualified operator name in an expression, there is a
1801
special provision: you must write
1803
<literal>OPERATOR(</><replaceable>schema</><literal>.</><replaceable>operator</><literal>)</>
1805
This is needed to avoid syntactic ambiguity. An example is:
1807
SELECT 3 OPERATOR(pg_catalog.+) 4;
1809
In practice one usually relies on the search path for operators,
1810
so as not to have to write anything so ugly as that.
1814
<sect2 id="ddl-schemas-priv">
1815
<title>Schemas and Privileges</title>
1817
<indexterm zone="ddl-schemas-priv">
1818
<primary>privilege</primary>
1819
<secondary sortas="schemas">for schemas</secondary>
1823
By default, users cannot access any objects in schemas they do not
1824
own. To allow that, the owner of the schema must grant the
1825
<literal>USAGE</literal> privilege on the schema. To allow users
1826
to make use of the objects in the schema, additional privileges
1827
might need to be granted, as appropriate for the object.
1831
A user can also be allowed to create objects in someone else's
1832
schema. To allow that, the <literal>CREATE</literal> privilege on
1833
the schema needs to be granted. Note that by default, everyone
1834
has <literal>CREATE</literal> and <literal>USAGE</literal> privileges on
1836
<literal>public</literal>. This allows all users that are able to
1837
connect to a given database to create objects in its
1838
<literal>public</literal> schema. If you do
1839
not want to allow that, you can revoke that privilege:
1841
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
1843
(The first <quote>public</quote> is the schema, the second
1844
<quote>public</quote> means <quote>every user</quote>. In the
1845
first sense it is an identifier, in the second sense it is a
1846
key word, hence the different capitalization; recall the
1847
guidelines from <xref linkend="sql-syntax-identifiers">.)
1851
<sect2 id="ddl-schemas-catalog">
1852
<title>The System Catalog Schema</title>
1854
<indexterm zone="ddl-schemas-catalog">
1855
<primary>system catalog</primary>
1856
<secondary>schema</secondary>
1860
In addition to <literal>public</> and user-created schemas, each
1861
database contains a <literal>pg_catalog</> schema, which contains
1862
the system tables and all the built-in data types, functions, and
1863
operators. <literal>pg_catalog</> is always effectively part of
1864
the search path. If it is not named explicitly in the path then
1865
it is implicitly searched <emphasis>before</> searching the path's
1866
schemas. This ensures that built-in names will always be
1867
findable. However, you can explicitly place
1868
<literal>pg_catalog</> at the end of your search path if you
1869
prefer to have user-defined names override built-in names.
1873
In <productname>PostgreSQL</productname> versions before 7.3,
1874
table names beginning with <literal>pg_</> were reserved. This is
1875
no longer true: you can create such a table name if you wish, in
1876
any non-system schema. However, it's best to continue to avoid
1877
such names, to ensure that you won't suffer a conflict if some
1878
future version defines a system table named the same as your
1879
table. (With the default search path, an unqualified reference to
1880
your table name would then be resolved as the system table instead.)
1881
System tables will continue to follow the convention of having
1882
names beginning with <literal>pg_</>, so that they will not
1883
conflict with unqualified user-table names so long as users avoid
1884
the <literal>pg_</> prefix.
1888
<sect2 id="ddl-schemas-patterns">
1889
<title>Usage Patterns</title>
1892
Schemas can be used to organize your data in many ways. There are
1893
a few usage patterns that are recommended and are easily supported by
1894
the default configuration:
1898
If you do not create any schemas then all users access the
1899
public schema implicitly. This simulates the situation where
1900
schemas are not available at all. This setup is mainly
1901
recommended when there is only a single user or a few cooperating
1902
users in a database. This setup also allows smooth transition
1903
from the non-schema-aware world.
1909
You can create a schema for each user with the same name as
1910
that user. Recall that the default search path starts with
1911
<literal>$user</literal>, which resolves to the user name.
1912
Therefore, if each user has a separate schema, they access their
1913
own schemas by default.
1917
If you use this setup then you might also want to revoke access
1918
to the public schema (or drop it altogether), so users are
1919
truly constrained to their own schemas.
1925
To install shared applications (tables to be used by everyone,
1926
additional functions provided by third parties, etc.), put them
1927
into separate schemas. Remember to grant appropriate
1928
privileges to allow the other users to access them. Users can
1929
then refer to these additional objects by qualifying the names
1930
with a schema name, or they can put the additional schemas into
1931
their search path, as they choose.
1938
<sect2 id="ddl-schemas-portability">
1939
<title>Portability</title>
1942
In the SQL standard, the notion of objects in the same schema
1943
being owned by different users does not exist. Moreover, some
1944
implementations do not allow you to create schemas that have a
1945
different name than their owner. In fact, the concepts of schema
1946
and user are nearly equivalent in a database system that
1947
implements only the basic schema support specified in the
1948
standard. Therefore, many users consider qualified names to
1950
<literal><replaceable>username</>.<replaceable>tablename</></literal>.
1951
This is how <productname>PostgreSQL</productname> will effectively
1952
behave if you create a per-user schema for every user.
1956
Also, there is no concept of a <literal>public</> schema in the
1957
SQL standard. For maximum conformance to the standard, you should
1958
not use (perhaps even remove) the <literal>public</> schema.
1962
Of course, some SQL database systems might not implement schemas
1963
at all, or provide namespace support by allowing (possibly
1964
limited) cross-database access. If you need to work with those
1965
systems, then maximum portability would be achieved by not using
1971
<sect1 id="ddl-inherit">
1972
<title>Inheritance</title>
1975
<primary>inheritance</primary>
1979
<primary>table</primary>
1980
<secondary>inheritance</secondary>
1984
<productname>PostgreSQL</productname> implements table inheritance,
1985
which can be a useful tool for database designers. (SQL:1999 and
1986
later define a type inheritance feature, which differs in many
1987
respects from the features described here.)
1991
Let's start with an example: suppose we are trying to build a data
1992
model for cities. Each state has many cities, but only one
1993
capital. We want to be able to quickly retrieve the capital city
1994
for any particular state. This can be done by creating two tables,
1995
one for state capitals and one for cities that are not
1996
capitals. However, what happens when we want to ask for data about
1997
a city, regardless of whether it is a capital or not? The
1998
inheritance feature can help to resolve this problem. We define the
1999
<structname>capitals</structname> table so that it inherits from
2000
<structname>cities</structname>:
2003
CREATE TABLE cities (
2006
altitude int -- in feet
2009
CREATE TABLE capitals (
2011
) INHERITS (cities);
2014
In this case, the <structname>capitals</> table <firstterm>inherits</>
2015
all the columns of its parent table, <structname>cities</>. State
2016
capitals also have an extra column, <structfield>state</>, that shows
2021
In <productname>PostgreSQL</productname>, a table can inherit from
2022
zero or more other tables, and a query can reference either all
2023
rows of a table or all rows of a table plus all of its descendant tables.
2024
The latter behavior is the default.
2025
For example, the following query finds the names of all cities,
2026
including state capitals, that are located at an altitude over
2030
SELECT name, altitude
2032
WHERE altitude > 500;
2035
Given the sample data from the <productname>PostgreSQL</productname>
2036
tutorial (see <xref linkend="tutorial-sql-intro">), this returns:
2040
-----------+----------
2048
On the other hand, the following query finds all the cities that
2049
are not state capitals and are situated at an altitude over 500 feet:
2052
SELECT name, altitude
2054
WHERE altitude > 500;
2057
-----------+----------
2064
Here the <literal>ONLY</literal> keyword indicates that the query
2065
should apply only to <structname>cities</structname>, and not any tables
2066
below <structname>cities</structname> in the inheritance hierarchy. Many
2067
of the commands that we have already discussed —
2068
<command>SELECT</command>, <command>UPDATE</command> and
2069
<command>DELETE</command> — support the
2070
<literal>ONLY</literal> keyword.
2074
In some cases you might wish to know which table a particular row
2075
originated from. There is a system column called
2076
<structfield>tableoid</structfield> in each table which can tell you the
2080
SELECT c.tableoid, c.name, c.altitude
2082
WHERE c.altitude > 500;
2088
tableoid | name | altitude
2089
----------+-----------+----------
2090
139793 | Las Vegas | 2174
2091
139793 | Mariposa | 1953
2092
139798 | Madison | 845
2095
(If you try to reproduce this example, you will probably get
2096
different numeric OIDs.) By doing a join with
2097
<structname>pg_class</> you can see the actual table names:
2100
SELECT p.relname, c.name, c.altitude
2101
FROM cities c, pg_class p
2102
WHERE c.altitude > 500 AND c.tableoid = p.oid;
2108
relname | name | altitude
2109
----------+-----------+----------
2110
cities | Las Vegas | 2174
2111
cities | Mariposa | 1953
2112
capitals | Madison | 845
2117
Inheritance does not automatically propagate data from
2118
<command>INSERT</command> or <command>COPY</command> commands to
2119
other tables in the inheritance hierarchy. In our example, the
2120
following <command>INSERT</command> statement will fail:
2122
INSERT INTO cities (name, population, altitude, state)
2123
VALUES ('New York', NULL, NULL, 'NY');
2125
We might hope that the data would somehow be routed to the
2126
<structname>capitals</structname> table, but this does not happen:
2127
<command>INSERT</command> always inserts into exactly the table
2128
specified. In some cases it is possible to redirect the insertion
2129
using a rule (see <xref linkend="rules">). However that does not
2130
help for the above case because the <structname>cities</> table
2131
does not contain the column <structfield>state</>, and so the
2132
command will be rejected before the rule can be applied.
2136
All check constraints and not-null constraints on a parent table are
2137
automatically inherited by its children. Other types of constraints
2138
(unique, primary key, and foreign key constraints) are not inherited.
2142
A table can inherit from more than one parent table, in which case it has
2143
the union of the columns defined by the parent tables. Any columns
2144
declared in the child table's definition are added to these. If the
2145
same column name appears in multiple parent tables, or in both a parent
2146
table and the child's definition, then these columns are <quote>merged</>
2147
so that there is only one such column in the child table. To be merged,
2148
columns must have the same data types, else an error is raised. The
2149
merged column will have copies of all the check constraints coming from
2150
any one of the column definitions it came from, and will be marked not-null
2155
Table inheritance is typically established when the child table is
2156
created, using the <literal>INHERITS</> clause of the
2157
<xref linkend="sql-createtable">
2159
Alternatively, a table which is already defined in a compatible way can
2160
have a new parent relationship added, using the <literal>INHERIT</literal>
2161
variant of <xref linkend="sql-altertable">.
2162
To do this the new child table must already include columns with
2163
the same names and types as the columns of the parent. It must also include
2164
check constraints with the same names and check expressions as those of the
2165
parent. Similarly an inheritance link can be removed from a child using the
2166
<literal>NO INHERIT</literal> variant of <command>ALTER TABLE</>.
2167
Dynamically adding and removing inheritance links like this can be useful
2168
when the inheritance relationship is being used for table
2169
partitioning (see <xref linkend="ddl-partitioning">).
2173
One convenient way to create a compatible table that will later be made
2174
a new child is to use the <literal>LIKE</literal> clause in <command>CREATE
2175
TABLE</command>. This creates a new table with the same columns as
2176
the source table. If there are any <literal>CHECK</literal>
2177
constraints defined on the source table, the <literal>INCLUDING
2178
CONSTRAINTS</literal> option to <literal>LIKE</literal> should be
2179
specified, as the new child must have constraints matching the parent
2180
to be considered compatible.
2184
A parent table cannot be dropped while any of its children remain. Neither
2185
can columns or check constraints of child tables be dropped or altered
2186
if they are inherited
2187
from any parent tables. If you wish to remove a table and all of its
2188
descendants, one easy way is to drop the parent table with the
2189
<literal>CASCADE</literal> option.
2193
<xref linkend="sql-altertable"> will
2194
propagate any changes in column data definitions and check
2195
constraints down the inheritance hierarchy. Again, dropping
2196
columns that are depended on by other tables is only possible when using
2197
the <literal>CASCADE</literal> option. <command>ALTER
2198
TABLE</command> follows the same rules for duplicate column merging
2199
and rejection that apply during <command>CREATE TABLE</command>.
2203
Note how table access permissions are handled. Querying a parent
2204
table can automatically access data in child tables without further
2205
access privilege checking. This preserves the appearance that the
2206
data is (also) in the parent table. Accessing the child tables
2207
directly is, however, not automatically allowed and would require
2208
further privileges to be granted.
2211
<sect2 id="ddl-inherit-caveats">
2212
<title>Caveats</title>
2215
Note that not all SQL commands are able to work on
2216
inheritance hierarchies. Commands that are used for data querying,
2217
data modification, or schema modification
2218
(e.g., <literal>SELECT</literal>, <literal>UPDATE</literal>, <literal>DELETE</literal>,
2219
most variants of <literal>ALTER TABLE</literal>, but
2220
not <literal>INSERT</literal> and <literal>ALTER TABLE ...
2221
RENAME</literal>) typically default to including child tables and
2222
support the <literal>ONLY</literal> notation to exclude them.
2223
Commands that do database maintenance and tuning
2224
(e.g., <literal>REINDEX</literal>, <literal>VACUUM</literal>)
2225
typically only work on individual, physical tables and do no
2226
support recursing over inheritance hierarchies. The respective
2227
behavior of each individual command is documented in the reference
2228
part (<xref linkend="sql-commands">).
2232
A serious limitation of the inheritance feature is that indexes (including
2233
unique constraints) and foreign key constraints only apply to single
2234
tables, not to their inheritance children. This is true on both the
2235
referencing and referenced sides of a foreign key constraint. Thus,
2236
in the terms of the above example:
2241
If we declared <structname>cities</>.<structfield>name</> to be
2242
<literal>UNIQUE</> or a <literal>PRIMARY KEY</>, this would not stop the
2243
<structname>capitals</> table from having rows with names duplicating
2244
rows in <structname>cities</>. And those duplicate rows would by
2245
default show up in queries from <structname>cities</>. In fact, by
2246
default <structname>capitals</> would have no unique constraint at all,
2247
and so could contain multiple rows with the same name.
2248
You could add a unique constraint to <structname>capitals</>, but this
2249
would not prevent duplication compared to <structname>cities</>.
2255
Similarly, if we were to specify that
2256
<structname>cities</>.<structfield>name</> <literal>REFERENCES</> some
2257
other table, this constraint would not automatically propagate to
2258
<structname>capitals</>. In this case you could work around it by
2259
manually adding the same <literal>REFERENCES</> constraint to
2260
<structname>capitals</>.
2266
Specifying that another table's column <literal>REFERENCES
2267
cities(name)</> would allow the other table to contain city names, but
2268
not capital names. There is no good workaround for this case.
2273
These deficiencies will probably be fixed in some future release,
2274
but in the meantime considerable care is needed in deciding whether
2275
inheritance is useful for your application.
2279
<title>Deprecated</title>
2281
In releases of <productname>PostgreSQL</productname> prior to 7.1, the
2282
default behavior was not to include child tables in queries. This was
2283
found to be error prone and also in violation of the SQL
2284
standard. You can get the pre-7.1 behavior by turning off the
2285
<xref linkend="guc-sql-inheritance"> configuration
2293
<sect1 id="ddl-partitioning">
2294
<title>Partitioning</title>
2297
<primary>partitioning</primary>
2301
<primary>table</primary>
2302
<secondary>partitioning</secondary>
2306
<productname>PostgreSQL</productname> supports basic table
2307
partitioning. This section describes why and how to implement
2308
partitioning as part of your database design.
2311
<sect2 id="ddl-partitioning-overview">
2312
<title>Overview</title>
2315
Partitioning refers to splitting what is logically one large table
2316
into smaller physical pieces.
2317
Partitioning can provide several benefits:
2321
Query performance can be improved dramatically in certain situations,
2322
particularly when most of the heavily accessed rows of the table are in a
2323
single partition or a small number of partitions. The partitioning
2324
substitutes for leading columns of indexes, reducing index size and
2325
making it more likely that the heavily-used parts of the indexes
2332
When queries or updates access a large percentage of a single
2333
partition, performance can be improved by taking advantage
2334
of sequential scan of that partition instead of using an
2335
index and random access reads scattered across the whole table.
2341
Bulk loads and deletes can be accomplished by adding or removing
2342
partitions, if that requirement is planned into the partitioning design.
2343
<command>ALTER TABLE</> is far faster than a bulk operation.
2344
It also entirely avoids the <command>VACUUM</command>
2345
overhead caused by a bulk <command>DELETE</>.
2351
Seldom-used data can be migrated to cheaper and slower storage media.
2356
The benefits will normally be worthwhile only when a table would
2357
otherwise be very large. The exact point at which a table will
2358
benefit from partitioning depends on the application, although a
2359
rule of thumb is that the size of the table should exceed the physical
2360
memory of the database server.
2364
Currently, <productname>PostgreSQL</productname> supports partitioning
2365
via table inheritance. Each partition must be created as a child
2366
table of a single parent table. The parent table itself is normally
2367
empty; it exists just to represent the entire data set. You should be
2368
familiar with inheritance (see <xref linkend="ddl-inherit">) before
2369
attempting to set up partitioning.
2373
The following forms of partitioning can be implemented in
2374
<productname>PostgreSQL</productname>:
2378
<term>Range Partitioning</term>
2382
The table is partitioned into <quote>ranges</quote> defined
2383
by a key column or set of columns, with no overlap between
2384
the ranges of values assigned to different partitions. For
2385
example one might partition by date ranges, or by ranges of
2386
identifiers for particular business objects.
2392
<term>List Partitioning</term>
2396
The table is partitioned by explicitly listing which key values
2397
appear in each partition.
2405
<sect2 id="ddl-partitioning-implementation">
2406
<title>Implementing Partitioning</title>
2409
To set up a partitioned table, do the following:
2410
<orderedlist spacing="compact">
2413
Create the <quote>master</quote> table, from which all of the
2414
partitions will inherit.
2417
This table will contain no data. Do not define any check
2418
constraints on this table, unless you intend them to
2419
be applied equally to all partitions. There is no point
2420
in defining any indexes or unique constraints on it, either.
2426
Create several <quote>child</quote> tables that each inherit from
2427
the master table. Normally, these tables will not add any columns
2428
to the set inherited from the master.
2432
We will refer to the child tables as partitions, though they
2433
are in every way normal <productname>PostgreSQL</> tables.
2439
Add table constraints to the partition tables to define the
2440
allowed key values in each partition.
2444
Typical examples would be:
2447
CHECK ( county IN ( 'Oxfordshire', 'Buckinghamshire', 'Warwickshire' ))
2448
CHECK ( outletID >= 100 AND outletID < 200 )
2450
Ensure that the constraints guarantee that there is no overlap
2451
between the key values permitted in different partitions. A common
2452
mistake is to set up range constraints like:
2454
CHECK ( outletID BETWEEN 100 AND 200 )
2455
CHECK ( outletID BETWEEN 200 AND 300 )
2457
This is wrong since it is not clear which partition the key value
2462
Note that there is no difference in
2463
syntax between range and list partitioning; those terms are
2470
For each partition, create an index on the key column(s),
2471
as well as any other indexes you might want. (The key index is
2472
not strictly necessary, but in most scenarios it is helpful.
2473
If you intend the key values to be unique then you should
2474
always create a unique or primary-key constraint for each
2481
Optionally, define a trigger or rule to redirect data inserted into
2482
the master table to the appropriate partition.
2488
Ensure that the <xref linkend="guc-constraint-exclusion">
2489
configuration parameter is not disabled in
2490
<filename>postgresql.conf</>.
2491
If it is, queries will not be optimized as desired.
2499
For example, suppose we are constructing a database for a large
2500
ice cream company. The company measures peak temperatures every
2501
day as well as ice cream sales in each region. Conceptually,
2502
we want a table like:
2505
CREATE TABLE measurement (
2506
city_id int not null,
2507
logdate date not null,
2513
We know that most queries will access just the last week's, month's or
2514
quarter's data, since the main use of this table will be to prepare
2515
online reports for management.
2516
To reduce the amount of old data that needs to be stored, we
2517
decide to only keep the most recent 3 years worth of data. At the
2518
beginning of each month we will remove the oldest month's data.
2522
In this situation we can use partitioning to help us meet all of our
2523
different requirements for the measurements table. Following the
2524
steps outlined above, partitioning can be set up as follows:
2528
<orderedlist spacing="compact">
2531
The master table is the <structname>measurement</> table, declared
2538
Next we create one partition for each active month:
2541
CREATE TABLE measurement_y2006m02 ( ) INHERITS (measurement);
2542
CREATE TABLE measurement_y2006m03 ( ) INHERITS (measurement);
2544
CREATE TABLE measurement_y2007m11 ( ) INHERITS (measurement);
2545
CREATE TABLE measurement_y2007m12 ( ) INHERITS (measurement);
2546
CREATE TABLE measurement_y2008m01 ( ) INHERITS (measurement);
2549
Each of the partitions are complete tables in their own right,
2550
but they inherit their definitions from the
2551
<structname>measurement</> table.
2555
This solves one of our problems: deleting old data. Each
2556
month, all we will need to do is perform a <command>DROP
2557
TABLE</command> on the oldest child table and create a new
2558
child table for the new month's data.
2564
We must provide non-overlapping table constraints. Rather than
2565
just creating the partition tables as above, the table creation
2566
script should really be:
2569
CREATE TABLE measurement_y2006m02 (
2570
CHECK ( logdate >= DATE '2006-02-01' AND logdate < DATE '2006-03-01' )
2571
) INHERITS (measurement);
2572
CREATE TABLE measurement_y2006m03 (
2573
CHECK ( logdate >= DATE '2006-03-01' AND logdate < DATE '2006-04-01' )
2574
) INHERITS (measurement);
2576
CREATE TABLE measurement_y2007m11 (
2577
CHECK ( logdate >= DATE '2007-11-01' AND logdate < DATE '2007-12-01' )
2578
) INHERITS (measurement);
2579
CREATE TABLE measurement_y2007m12 (
2580
CHECK ( logdate >= DATE '2007-12-01' AND logdate < DATE '2008-01-01' )
2581
) INHERITS (measurement);
2582
CREATE TABLE measurement_y2008m01 (
2583
CHECK ( logdate >= DATE '2008-01-01' AND logdate < DATE '2008-02-01' )
2584
) INHERITS (measurement);
2591
We probably need indexes on the key columns too:
2594
CREATE INDEX measurement_y2006m02_logdate ON measurement_y2006m02 (logdate);
2595
CREATE INDEX measurement_y2006m03_logdate ON measurement_y2006m03 (logdate);
2597
CREATE INDEX measurement_y2007m11_logdate ON measurement_y2007m11 (logdate);
2598
CREATE INDEX measurement_y2007m12_logdate ON measurement_y2007m12 (logdate);
2599
CREATE INDEX measurement_y2008m01_logdate ON measurement_y2008m01 (logdate);
2602
We choose not to add further indexes at this time.
2608
We want our application to be able to say <literal>INSERT INTO
2609
measurement ...</> and have the data be redirected into the
2610
appropriate partition table. We can arrange that by attaching
2611
a suitable trigger function to the master table.
2612
If data will be added only to the latest partition, we can
2613
use a very simple trigger function:
2616
CREATE OR REPLACE FUNCTION measurement_insert_trigger()
2617
RETURNS TRIGGER AS $$
2619
INSERT INTO measurement_y2008m01 VALUES (NEW.*);
2626
After creating the function, we create a trigger which
2627
calls the trigger function:
2630
CREATE TRIGGER insert_measurement_trigger
2631
BEFORE INSERT ON measurement
2632
FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();
2635
We must redefine the trigger function each month so that it always
2636
points to the current partition. The trigger definition does
2637
not need to be updated, however.
2641
We might want to insert data and have the server automatically
2642
locate the partition into which the row should be added. We
2643
could do this with a more complex trigger function, for example:
2646
CREATE OR REPLACE FUNCTION measurement_insert_trigger()
2647
RETURNS TRIGGER AS $$
2649
IF ( NEW.logdate >= DATE '2006-02-01' AND
2650
NEW.logdate < DATE '2006-03-01' ) THEN
2651
INSERT INTO measurement_y2006m02 VALUES (NEW.*);
2652
ELSIF ( NEW.logdate >= DATE '2006-03-01' AND
2653
NEW.logdate < DATE '2006-04-01' ) THEN
2654
INSERT INTO measurement_y2006m03 VALUES (NEW.*);
2656
ELSIF ( NEW.logdate >= DATE '2008-01-01' AND
2657
NEW.logdate < DATE '2008-02-01' ) THEN
2658
INSERT INTO measurement_y2008m01 VALUES (NEW.*);
2660
RAISE EXCEPTION 'Date out of range. Fix the measurement_insert_trigger() function!';
2668
The trigger definition is the same as before.
2669
Note that each <literal>IF</literal> test must exactly match the
2670
<literal>CHECK</literal> constraint for its partition.
2674
While this function is more complex than the single-month case,
2675
it doesn't need to be updated as often, since branches can be
2676
added in advance of being needed.
2681
In practice it might be best to check the newest partition first,
2682
if most inserts go into that partition. For simplicity we have
2683
shown the trigger's tests in the same order as in other parts
2692
As we can see, a complex partitioning scheme could require a
2693
substantial amount of DDL. In the above example we would be
2694
creating a new partition each month, so it might be wise to write a
2695
script that generates the required DDL automatically.
2700
<sect2 id="ddl-partitioning-managing-partitions">
2701
<title>Managing Partitions</title>
2704
Normally the set of partitions established when initially
2705
defining the table are not intended to remain static. It is
2706
common to want to remove old partitions of data and periodically
2707
add new partitions for new data. One of the most important
2708
advantages of partitioning is precisely that it allows this
2709
otherwise painful task to be executed nearly instantaneously by
2710
manipulating the partition structure, rather than physically moving large
2711
amounts of data around.
2715
The simplest option for removing old data is simply to drop the partition
2716
that is no longer necessary:
2718
DROP TABLE measurement_y2006m02;
2720
This can very quickly delete millions of records because it doesn't have
2721
to individually delete every record.
2725
Another option that is often preferable is to remove the partition from
2726
the partitioned table but retain access to it as a table in its own
2729
ALTER TABLE measurement_y2006m02 NO INHERIT measurement;
2731
This allows further operations to be performed on the data before
2732
it is dropped. For example, this is often a useful time to back up
2733
the data using <command>COPY</>, <application>pg_dump</>, or
2734
similar tools. It might also be a useful time to aggregate data
2735
into smaller formats, perform other data manipulations, or run
2740
Similarly we can add a new partition to handle new data. We can create an
2741
empty partition in the partitioned table just as the original partitions
2745
CREATE TABLE measurement_y2008m02 (
2746
CHECK ( logdate >= DATE '2008-02-01' AND logdate < DATE '2008-03-01' )
2747
) INHERITS (measurement);
2750
As an alternative, it is sometimes more convenient to create the
2751
new table outside the partition structure, and make it a proper
2752
partition later. This allows the data to be loaded, checked, and
2753
transformed prior to it appearing in the partitioned table:
2756
CREATE TABLE measurement_y2008m02
2757
(LIKE measurement INCLUDING DEFAULTS INCLUDING CONSTRAINTS);
2758
ALTER TABLE measurement_y2008m02 ADD CONSTRAINT y2008m02
2759
CHECK ( logdate >= DATE '2008-02-01' AND logdate < DATE '2008-03-01' );
2760
\copy measurement_y2008m02 from 'measurement_y2008m02'
2761
-- possibly some other data preparation work
2762
ALTER TABLE measurement_y2008m02 INHERIT measurement;
2767
<sect2 id="ddl-partitioning-constraint-exclusion">
2768
<title>Partitioning and Constraint Exclusion</title>
2771
<primary>constraint exclusion</primary>
2775
<firstterm>Constraint exclusion</> is a query optimization technique
2776
that improves performance for partitioned tables defined in the
2777
fashion described above. As an example:
2780
SET constraint_exclusion = on;
2781
SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
2784
Without constraint exclusion, the above query would scan each of
2785
the partitions of the <structname>measurement</> table. With constraint
2786
exclusion enabled, the planner will examine the constraints of each
2787
partition and try to prove that the partition need not
2788
be scanned because it could not contain any rows meeting the query's
2789
<literal>WHERE</> clause. When the planner can prove this, it
2790
excludes the partition from the query plan.
2794
You can use the <command>EXPLAIN</> command to show the difference
2795
between a plan with <varname>constraint_exclusion</> on and a plan
2796
with it off. A typical unoptimized plan for this type of table setup is:
2799
SET constraint_exclusion = off;
2800
EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
2803
-----------------------------------------------------------------------------------------------
2804
Aggregate (cost=158.66..158.68 rows=1 width=0)
2805
-> Append (cost=0.00..151.88 rows=2715 width=0)
2806
-> Seq Scan on measurement (cost=0.00..30.38 rows=543 width=0)
2807
Filter: (logdate >= '2008-01-01'::date)
2808
-> Seq Scan on measurement_y2006m02 measurement (cost=0.00..30.38 rows=543 width=0)
2809
Filter: (logdate >= '2008-01-01'::date)
2810
-> Seq Scan on measurement_y2006m03 measurement (cost=0.00..30.38 rows=543 width=0)
2811
Filter: (logdate >= '2008-01-01'::date)
2813
-> Seq Scan on measurement_y2007m12 measurement (cost=0.00..30.38 rows=543 width=0)
2814
Filter: (logdate >= '2008-01-01'::date)
2815
-> Seq Scan on measurement_y2008m01 measurement (cost=0.00..30.38 rows=543 width=0)
2816
Filter: (logdate >= '2008-01-01'::date)
2819
Some or all of the partitions might use index scans instead of
2820
full-table sequential scans, but the point here is that there
2821
is no need to scan the older partitions at all to answer this query.
2822
When we enable constraint exclusion, we get a significantly
2823
cheaper plan that will deliver the same answer:
2826
SET constraint_exclusion = on;
2827
EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
2829
-----------------------------------------------------------------------------------------------
2830
Aggregate (cost=63.47..63.48 rows=1 width=0)
2831
-> Append (cost=0.00..60.75 rows=1086 width=0)
2832
-> Seq Scan on measurement (cost=0.00..30.38 rows=543 width=0)
2833
Filter: (logdate >= '2008-01-01'::date)
2834
-> Seq Scan on measurement_y2008m01 measurement (cost=0.00..30.38 rows=543 width=0)
2835
Filter: (logdate >= '2008-01-01'::date)
2840
Note that constraint exclusion is driven only by <literal>CHECK</>
2841
constraints, not by the presence of indexes. Therefore it isn't
2842
necessary to define indexes on the key columns. Whether an index
2843
needs to be created for a given partition depends on whether you
2844
expect that queries that scan the partition will generally scan
2845
a large part of the partition or just a small part. An index will
2846
be helpful in the latter case but not the former.
2850
The default (and recommended) setting of
2851
<xref linkend="guc-constraint-exclusion"> is actually neither
2852
<literal>on</> nor <literal>off</>, but an intermediate setting
2853
called <literal>partition</>, which causes the technique to be
2854
applied only to queries that are likely to be working on partitioned
2855
tables. The <literal>on</> setting causes the planner to examine
2856
<literal>CHECK</> constraints in all queries, even simple ones that
2857
are unlikely to benefit.
2862
<sect2 id="ddl-partitioning-alternatives">
2863
<title>Alternative Partitioning Methods</title>
2866
A different approach to redirecting inserts into the appropriate
2867
partition table is to set up rules, instead of a trigger, on the
2868
master table. For example:
2871
CREATE RULE measurement_insert_y2006m02 AS
2872
ON INSERT TO measurement WHERE
2873
( logdate >= DATE '2006-02-01' AND logdate < DATE '2006-03-01' )
2875
INSERT INTO measurement_y2006m02 VALUES (NEW.*);
2877
CREATE RULE measurement_insert_y2008m01 AS
2878
ON INSERT TO measurement WHERE
2879
( logdate >= DATE '2008-01-01' AND logdate < DATE '2008-02-01' )
2881
INSERT INTO measurement_y2008m01 VALUES (NEW.*);
2884
A rule has significantly more overhead than a trigger, but the overhead
2885
is paid once per query rather than once per row, so this method might be
2886
advantageous for bulk-insert situations. In most cases, however, the
2887
trigger method will offer better performance.
2891
Be aware that <command>COPY</> ignores rules. If you want to
2892
use <command>COPY</> to insert data, you'll need to copy into the correct
2893
partition table rather than into the master. <command>COPY</> does fire
2894
triggers, so you can use it normally if you use the trigger approach.
2898
Another disadvantage of the rule approach is that there is no simple
2899
way to force an error if the set of rules doesn't cover the insertion
2900
date; the data will silently go into the master table instead.
2904
Partitioning can also be arranged using a <literal>UNION ALL</literal>
2905
view, instead of table inheritance. For example,
2908
CREATE VIEW measurement AS
2909
SELECT * FROM measurement_y2006m02
2910
UNION ALL SELECT * FROM measurement_y2006m03
2912
UNION ALL SELECT * FROM measurement_y2007m11
2913
UNION ALL SELECT * FROM measurement_y2007m12
2914
UNION ALL SELECT * FROM measurement_y2008m01;
2917
However, the need to recreate the view adds an extra step to adding and
2918
dropping individual partitions of the data set. In practice this
2919
method has little to recommend it compared to using inheritance.
2924
<sect2 id="ddl-partitioning-caveats">
2925
<title>Caveats</title>
2928
The following caveats apply to partitioned tables:
2932
There is no automatic way to verify that all of the
2933
<literal>CHECK</literal> constraints are mutually
2934
exclusive. It is safer to create code that generates
2935
partitions and creates and/or modifies associated objects than
2936
to write each by hand.
2942
The schemes shown here assume that the partition key column(s)
2943
of a row never change, or at least do not change enough to require
2944
it to move to another partition. An <command>UPDATE</> that attempts
2945
to do that will fail because of the <literal>CHECK</> constraints.
2946
If you need to handle such cases, you can put suitable update triggers
2947
on the partition tables, but it makes management of the structure
2948
much more complicated.
2954
If you are using manual <command>VACUUM</command> or
2955
<command>ANALYZE</command> commands, don't forget that
2956
you need to run them on each partition individually. A command like:
2958
ANALYZE measurement;
2960
will only process the master table.
2968
The following caveats apply to constraint exclusion:
2973
Constraint exclusion only works when the query's <literal>WHERE</>
2974
clause contains constants. A parameterized query will not be
2975
optimized, since the planner cannot know which partitions the
2976
parameter value might select at run time. For the same reason,
2977
<quote>stable</> functions such as <function>CURRENT_DATE</function>
2984
Keep the partitioning constraints simple, else the planner may not be
2985
able to prove that partitions don't need to be visited. Use simple
2986
equality conditions for list partitioning, or simple
2987
range tests for range partitioning, as illustrated in the preceding
2988
examples. A good rule of thumb is that partitioning constraints should
2989
contain only comparisons of the partitioning column(s) to constants
2990
using B-tree-indexable operators.
2996
All constraints on all partitions of the master table are examined
2997
during constraint exclusion, so large numbers of partitions are likely
2998
to increase query planning time considerably. Partitioning using
2999
these techniques will work well with up to perhaps a hundred partitions;
3000
don't try to use many thousands of partitions.
3009
<sect1 id="ddl-foreign-data">
3010
<title>Foreign Data</title>
3013
<primary>foreign data</primary>
3016
<primary>foreign table</primary>
3020
<productname>PostgreSQL</productname> implements portions of the SQL/MED
3021
specification, allowing you to access data that resides outside
3022
PostgreSQL using regular SQL queries. Such data is referred to as
3023
<firstterm>foreign data</>. (Note that this usage is not to be confused
3024
with foreign keys, which are a type of constraint within the database.)
3028
Foreign data is accessed with help from a
3029
<firstterm>foreign data wrapper</firstterm>. A foreign data wrapper is a
3030
library that can communicate with an external data source, hiding the
3031
details of connecting to the data source and fetching data from it. There
3032
are several foreign data wrappers available, which can for example read
3033
plain data files residing on the server, or connect to another PostgreSQL
3034
instance. If none of the existing foreign data wrappers suit your needs,
3035
you can write your own; see <xref linkend="fdwhandler">.
3039
To access foreign data, you need to create a <firstterm>foreign server</>
3040
object, which defines how to connect to a particular external data source,
3041
according to the set of options used by a particular foreign data
3042
wrapper. Then you need to create one or more <firstterm>foreign
3043
tables</firstterm>, which define the structure of the remote data. A
3044
foreign table can be used in queries just like a normal table, but a
3045
foreign table has no storage in the PostgreSQL server. Whenever it is
3046
used, PostgreSQL asks the foreign data wrapper to fetch the data from the
3051
Currently, foreign tables are read-only. This limitation may be fixed
3052
in a future release.
3056
<sect1 id="ddl-others">
3057
<title>Other Database Objects</title>
3060
Tables are the central objects in a relational database structure,
3061
because they hold your data. But they are not the only objects
3062
that exist in a database. Many other kinds of objects can be
3063
created to make the use and management of the data more efficient
3064
or convenient. They are not discussed in this chapter, but we give
3065
you a list here so that you are aware of what is possible:
3077
Functions and operators
3083
Data types and domains
3089
Triggers and rewrite rules
3095
Detailed information on
3096
these topics appears in <xref linkend="server-programming">.
3100
<sect1 id="ddl-depend">
3101
<title>Dependency Tracking</title>
3103
<indexterm zone="ddl-depend">
3104
<primary>CASCADE</primary>
3105
<secondary sortas="DROP">with DROP</secondary>
3108
<indexterm zone="ddl-depend">
3109
<primary>RESTRICT</primary>
3110
<secondary sortas="DROP">with DROP</secondary>
3114
When you create complex database structures involving many tables
3115
with foreign key constraints, views, triggers, functions, etc. you
3116
implicitly create a net of dependencies between the objects.
3117
For instance, a table with a foreign key constraint depends on the
3118
table it references.
3122
To ensure the integrity of the entire database structure,
3123
<productname>PostgreSQL</productname> makes sure that you cannot
3124
drop objects that other objects still depend on. For example,
3125
attempting to drop the products table we had considered in <xref
3126
linkend="ddl-constraints-fk">, with the orders table depending on
3127
it, would result in an error message such as this:
3129
DROP TABLE products;
3131
NOTICE: constraint orders_product_no_fkey on table orders depends on table products
3132
ERROR: cannot drop table products because other objects depend on it
3133
HINT: Use DROP ... CASCADE to drop the dependent objects too.
3135
The error message contains a useful hint: if you do not want to
3136
bother deleting all the dependent objects individually, you can run:
3138
DROP TABLE products CASCADE;
3140
and all the dependent objects will be removed. In this case, it
3141
doesn't remove the orders table, it only removes the foreign key
3142
constraint. (If you want to check what <command>DROP ... CASCADE</> will do,
3143
run <command>DROP</> without <literal>CASCADE</> and read the <literal>NOTICE</> messages.)
3147
All drop commands in <productname>PostgreSQL</productname> support
3148
specifying <literal>CASCADE</literal>. Of course, the nature of
3149
the possible dependencies varies with the type of the object. You
3150
can also write <literal>RESTRICT</literal> instead of
3151
<literal>CASCADE</literal> to get the default behavior, which is to
3152
prevent the dropping of objects that other objects depend on.
3157
According to the SQL standard, specifying either
3158
<literal>RESTRICT</literal> or <literal>CASCADE</literal> is
3159
required. No database system actually enforces that rule, but
3160
whether the default behavior is <literal>RESTRICT</literal> or
3161
<literal>CASCADE</literal> varies across systems.
3167
Foreign key constraint dependencies and serial column dependencies
3168
from <productname>PostgreSQL</productname> versions prior to 7.3
3169
are <emphasis>not</emphasis> maintained or created during the
3170
upgrade process. All other dependency types will be properly
3171
created during an upgrade from a pre-7.3 database.
added
removed
doc/src/sgml/ddl.sgml
