+ linkend="sql-syntax-row-constructors">.
+
+
+
+
+
Accessing Composite Types
+
+ 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 on_hand example table with something
+ like:
+
+SELECT item.name FROM on_hand WHERE item.price > 9.99;
+
+
+ This will not work since the name item is taken to be a table
+ name, not a field name, per SQL syntax rules. You must write it like this:
+
+SELECT (item).name FROM on_hand WHERE (item).price > 9.99;
+
+
+ or if you need to use the table name as well (for instance in a multi-table
+ query), like this:
+
+SELECT (on_hand.item).name FROM on_hand WHERE (on_hand.item).price > 9.99;
+
+
+ Now the parenthesized object is correctly interpreted as a reference to
+ the item column, and then the subfield can be selected from it.
+
+
+ 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
+
+SELECT (my_func(...)).field FROM ...
+
+
+ Without the extra parentheses, this will provoke a syntax error.
+
+
+
+
+
Composite Type Input and Output Syntax
+
+ 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 (( and ))
+ around the whole value, plus commas (,) between adjacent
+ items. Whitespace outside the parentheses is ignored, but within the
+ parentheses it is considered part of the field value, and may or may not be
+ significant depending on the input conversion rules for the field datatype.
+ For example, in
+'( 42)'
+
+ the whitespace will be ignored if the field type is integer, but not if
+ it is text.
+
+
+ As shown previously, when writing a composite value you may write double
+ quotes around any individual field value.
+ You must 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 use backslash-escaping to protect all data characters
+ that would otherwise be taken as composite syntax.
+
+
+ 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 "".
+
+
+ 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.
+
+
+
+ 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. For example, to insert a text field
+ containing a double quote and a backslash in a composite
+ value, you'd need to write
+INSERT ... VALUES ('("\\"\\\\")');
+
+ The string-literal processor removes one level of backslashes, so that
+ what arrives at the composite-value parser looks like
+ ("\"\\"). In turn, the string
+ fed to the text data type's input routine
+ becomes "\. (If we were working
+ with a data type whose input routine also treated backslashes specially,
+ bytea for example, we might need as many as eight backslashes
+ in the command to get one backslash into the stored composite field.)
+
+
+
+
+ The ROW constructor syntax is usually easier to work with
+ than the composite-literal syntax when writing composite values in SQL
+ commands.
+ In ROW, individual field values are written the same way
+ they would be written when not members of a composite.
+
+
+
+
+
projects / postgresql.git / commitdiff