~ubuntu-branches/ubuntu/trusty/postgresql-9.3/trusty-updates : contents of doc/src/sgml/html/rowtypes.html at revision 27

~ubuntu-branches/ubuntu/trusty/postgresql-9.3/trusty-updates : (revision 27)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Composite Types</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.3.13 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Data Types"
HREF="datatype.html"><LINK
REL="PREVIOUS"
TITLE="Arrays"
HREF="arrays.html"><LINK
REL="NEXT"
TITLE="Range Types"
HREF="rangetypes.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2016-05-09T21:13:26"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.3.13 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Arrays"
HREF="arrays.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="datatype.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 8. Data Types</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Range Types"
HREF="rangetypes.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="ROWTYPES"
>8.16. Composite Types</A
></H1
><P
>  A <I
CLASS="FIRSTTERM"
>composite type</I
> represents the structure of a row or record;
  it is essentially just a list of field names and their data types.
  <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> allows  composite types to be
  used in many of the same ways that simple types can be used.  For example, a
  column of a table can be declared to be of a composite type.
 </P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN7414"
>8.16.1. Declaration of Composite Types</A
></H2
><P
>  Here are two simple examples of defining composite types:
</P><PRE
CLASS="PROGRAMLISTING"
>CREATE TYPE complex AS (
    r       double precision,
    i       double precision
);

CREATE TYPE inventory_item AS (
    name            text,
    supplier_id     integer,
    price           numeric
);</PRE
><P>
  The syntax is comparable to <TT
CLASS="COMMAND"
>CREATE TABLE</TT
>, except that only
  field names and types can be specified; no constraints (such as <TT
CLASS="LITERAL"
>NOT
  NULL</TT
>) can presently be included.  Note that the <TT
CLASS="LITERAL"
>AS</TT
> keyword
  is essential; without it, the system will think a different kind
  of <TT
CLASS="COMMAND"
>CREATE TYPE</TT
> command is meant, and you will get odd syntax
  errors.
 </P
><P
>  Having defined the types, we can use them to create tables:

</P><PRE
CLASS="PROGRAMLISTING"
>CREATE TABLE on_hand (
    item      inventory_item,
    count     integer
);

INSERT INTO on_hand VALUES (ROW('fuzzy dice', 42, 1.99), 1000);</PRE
><P>

  or functions:

</P><PRE
CLASS="PROGRAMLISTING"
>CREATE FUNCTION price_extension(inventory_item, integer) RETURNS numeric
AS 'SELECT $1.price * $2' LANGUAGE SQL;

SELECT price_extension(item, 10) FROM on_hand;</PRE
><P>

 </P
><P
>  Whenever you create a table, a composite type is also automatically
  created, with the same name as the table, to represent the table's
  row type.  For example, had we said:
</P><PRE
CLASS="PROGRAMLISTING"
>CREATE TABLE inventory_item (
    name            text,
    supplier_id     integer REFERENCES suppliers,
    price           numeric CHECK (price &gt; 0)
);</PRE
><P>
  then the same <TT
CLASS="LITERAL"
>inventory_item</TT
> composite type shown above would
  come into being as a
  byproduct, and could be used just as above.  Note however an important
  restriction of the current implementation: since no constraints are
  associated with a composite type, the constraints shown in the table
  definition <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>do not apply</I
></SPAN
> to values of the composite type
  outside the table.  (A partial workaround is to use domain
  types as members of composite types.)
 </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN7429"
>8.16.2. Composite Value Input</A
></H2
><P
>   To write a composite value as a literal constant, enclose the field
   values within parentheses and separate them by commas.  You can put double
   quotes around any field value, and must do so if it contains commas or
   parentheses.  (More details appear below.)  Thus, the general format of a
   composite constant is the following:
</P><PRE
CLASS="SYNOPSIS"
>'( <TT
CLASS="REPLACEABLE"
><I
>val1</I
></TT
> , <TT
CLASS="REPLACEABLE"
><I
>val2</I
></TT
> , ... )'</PRE
><P>
   An example is:
</P><PRE
CLASS="PROGRAMLISTING"
>'("fuzzy dice",42,1.99)'</PRE
><P>
   which would be a valid value of the <TT
CLASS="LITERAL"
>inventory_item</TT
> type
   defined above.  To make a field be NULL, write no characters at all
   in its position in the list.  For example, this constant specifies
   a NULL third field:
</P><PRE
CLASS="PROGRAMLISTING"
>'("fuzzy dice",42,)'</PRE
><P>
   If you want an empty string rather than NULL, write double quotes:
</P><PRE
CLASS="PROGRAMLISTING"
>'("",42,)'</PRE
><P>
   Here the first field is a non-NULL empty string, the third is NULL.
  </P
><P
>   (These constants are actually only a special case of
   the generic type constants discussed in <A
HREF="sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS-GENERIC"
>Section 4.1.2.7</A
>.  The constant is initially
   treated as a string and passed to the composite-type input conversion
   routine.  An explicit type specification might be necessary.)
  </P
><P
>  The <TT
CLASS="LITERAL"
>ROW</TT
> expression syntax can also be used to
  construct composite values.  In most cases this is considerably
  simpler to use than the string-literal syntax since you don't have
  to worry about multiple layers of quoting.  We already used this
  method above:
</P><PRE
CLASS="PROGRAMLISTING"
>ROW('fuzzy dice', 42, 1.99)
ROW('', 42, NULL)</PRE
><P>
  The ROW keyword is actually optional as long as you have more than one
  field in the expression, so these can simplify to:
</P><PRE
CLASS="PROGRAMLISTING"
>('fuzzy dice', 42, 1.99)
('', 42, NULL)</PRE
><P>
  The <TT
CLASS="LITERAL"
>ROW</TT
> expression syntax is discussed in more detail in <A
HREF="sql-expressions.html#SQL-SYNTAX-ROW-CONSTRUCTORS"
>Section 4.2.13</A
>.
 </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN7450"
>8.16.3. Accessing Composite Types</A
></H2
><P
>  To access a field of a composite column, one writes a dot and the field
  name, much like selecting a field from a table name.  In fact, it's so
  much like selecting from a table name that you often have to use parentheses
  to keep from confusing the parser.  For example, you might try to select
  some subfields from our <TT
CLASS="LITERAL"
>on_hand</TT
> example table with something
  like:

</P><PRE
CLASS="PROGRAMLISTING"
>SELECT item.name FROM on_hand WHERE item.price &gt; 9.99;</PRE
><P>

  This will not work since the name <TT
CLASS="LITERAL"
>item</TT
> is taken to be a table
  name, not a column name of <TT
CLASS="LITERAL"
>on_hand</TT
>, per SQL syntax rules.
  You must write it like this:

</P><PRE
CLASS="PROGRAMLISTING"
>SELECT (item).name FROM on_hand WHERE (item).price &gt; 9.99;</PRE
><P>

  or if you need to use the table name as well (for instance in a multitable
  query), like this:

</P><PRE
CLASS="PROGRAMLISTING"
>SELECT (on_hand.item).name FROM on_hand WHERE (on_hand.item).price &gt; 9.99;</PRE
><P>

  Now the parenthesized object is correctly interpreted as a reference to
  the <TT
CLASS="LITERAL"
>item</TT
> column, and then the subfield can be selected from it.
 </P
><P
>  Similar syntactic issues apply whenever you select a field from a composite
  value.  For instance, to select just one field from the result of a function
  that returns a composite value, you'd need to write something like:

</P><PRE
CLASS="PROGRAMLISTING"
>SELECT (my_func(...)).field FROM ...</PRE
><P>

  Without the extra parentheses, this will generate a syntax error.
 </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN7462"
>8.16.4. Modifying Composite Types</A
></H2
><P
>  Here are some examples of the proper syntax for inserting and updating
  composite columns.
  First, inserting or updating a whole column:

</P><PRE
CLASS="PROGRAMLISTING"
>INSERT INTO mytab (complex_col) VALUES((1.1,2.2));

UPDATE mytab SET complex_col = ROW(1.1,2.2) WHERE ...;</PRE
><P>

  The first example omits <TT
CLASS="LITERAL"
>ROW</TT
>, the second uses it; we
  could have done it either way.
 </P
><P
>  We can update an individual subfield of a composite column:

</P><PRE
CLASS="PROGRAMLISTING"
>UPDATE mytab SET complex_col.r = (complex_col).r + 1 WHERE ...;</PRE
><P>

  Notice here that we don't need to (and indeed cannot)
  put parentheses around the column name appearing just after
  <TT
CLASS="LITERAL"
>SET</TT
>, but we do need parentheses when referencing the same
  column in the expression to the right of the equal sign.
 </P
><P
>  And we can specify subfields as targets for <TT
CLASS="COMMAND"
>INSERT</TT
>, too:

</P><PRE
CLASS="PROGRAMLISTING"
>INSERT INTO mytab (complex_col.r, complex_col.i) VALUES(1.1, 2.2);</PRE
><P>

  Had we not supplied values for all the subfields of the column, the
  remaining subfields would have been filled with null values.
 </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="ROWTYPES-IO-SYNTAX"
>8.16.5. Composite Type Input and Output Syntax</A
></H2
><P
>   The external text representation of a composite value consists of items that
   are interpreted according to the I/O conversion rules for the individual
   field types, plus decoration that indicates the composite structure.
   The decoration consists of parentheses (<TT
CLASS="LITERAL"
>(</TT
> and <TT
CLASS="LITERAL"
>)</TT
>)
   around the whole value, plus commas (<TT
CLASS="LITERAL"
>,</TT
>) between adjacent
   items.  Whitespace outside the parentheses is ignored, but within the
   parentheses it is considered part of the field value, and might or might not be
   significant depending on the input conversion rules for the field data type.
   For example, in:
</P><PRE
CLASS="PROGRAMLISTING"
>'(  42)'</PRE
><P>
   the whitespace will be ignored if the field type is integer, but not if
   it is text.
  </P
><P
>   As shown previously, when writing a composite value you can write double
   quotes around any individual field value.
   You <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>must</I
></SPAN
> do so if the field value would otherwise
   confuse the composite-value parser.  In particular, fields containing
   parentheses, commas, double quotes, or backslashes must be double-quoted.
   To put a double quote or backslash in a quoted composite field value,
   precede it with a backslash.  (Also, a pair of double quotes within a
   double-quoted field value is taken to represent a double quote character,
   analogously to the rules for single quotes in SQL literal strings.)
   Alternatively, you can avoid quoting and use backslash-escaping to
   protect all data characters
   that would otherwise be taken as composite syntax.
  </P
><P
>   A completely empty field value (no characters at all between the commas
   or parentheses) represents a NULL.  To write a value that is an empty
   string rather than NULL, write <TT
CLASS="LITERAL"
>""</TT
>.
  </P
><P
>   The composite output routine will put double quotes around field values
   if they are empty strings or contain parentheses, commas,
   double quotes, backslashes, or white space.  (Doing so for white space
   is not essential, but aids legibility.)  Double quotes and backslashes
   embedded in field values will be doubled.
  </P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>   Remember that what you write in an SQL command will first be interpreted
   as a string literal, and then as a composite.  This doubles the number of
   backslashes you need (assuming escape string syntax is used).
   For example, to insert a <TT
CLASS="TYPE"
>text</TT
> field
   containing a double quote and a backslash in a composite
   value, you'd need to write:
</P><PRE
CLASS="PROGRAMLISTING"
>INSERT ... VALUES (E'("\\"\\\\")');</PRE
><P>
   The string-literal processor removes one level of backslashes, so that
   what arrives at the composite-value parser looks like
   <TT
CLASS="LITERAL"
>("\"\\")</TT
>.  In turn, the string
   fed to the <TT
CLASS="TYPE"
>text</TT
> data type's input routine
   becomes <TT
CLASS="LITERAL"
>"\</TT
>.  (If we were working
   with a data type whose input routine also treated backslashes specially,
   <TT
CLASS="TYPE"
>bytea</TT
> for example, we might need as many as eight backslashes
   in the command to get one backslash into the stored composite field.)
   Dollar quoting (see <A
HREF="sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING"
>Section 4.1.2.4</A
>) can be
   used to avoid the need to double backslashes.
  </P
></BLOCKQUOTE
></DIV
><DIV
CLASS="TIP"
><BLOCKQUOTE
CLASS="TIP"
><P
><B
>Tip: </B
>   The <TT
CLASS="LITERAL"
>ROW</TT
> constructor syntax is usually easier to work with
   than the composite-literal syntax when writing composite values in SQL
   commands.
   In <TT
CLASS="LITERAL"
>ROW</TT
>, individual field values are written the same way
   they would be written when not members of a composite.
  </P
></BLOCKQUOTE
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="arrays.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="rangetypes.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Arrays</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="datatype.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Range Types</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>