+ linkend="rowtypes-accessing">above, you need to write parentheses
+ around the value that .* is applied to whenever it's not a
+ simple table name. For example, if myfunc() is a function
+ returning a composite type with columns a,
+ b, and c, then these two queries have the
+ same result:
+SELECT (myfunc(x)).* FROM some_table;
+SELECT (myfunc(x)).a, (myfunc(x)).b, (myfunc(x)).c FROM some_table;
+
+
+
+
+
PostgreSQL handles column expansion by+ actually transforming the first form into the second. So, in this
+ example, myfunc() would get invoked three times per row
+ with either syntax. If it's an expensive function you may wish to
+ avoid that, which you can do with a query like:
+SELECT (m).* FROM (SELECT myfunc(x) AS m FROM some_table OFFSET 0) ss;
+
+ The OFFSET 0 clause keeps the optimizer
+ from flattening the sub-select to arrive at the form with
+ multiple calls of myfunc().
+
+
+
+ The composite_value.* syntax results in
+ column expansion of this kind when it appears at the top level of
+ a SELECT output
+ list, a RETURNING
+ list in INSERT/UPDATE/DELETE,
+ a VALUES clause, or
+ a row constructor.
+ In all other contexts (including when nested inside one of those
+ constructs), attaching .* to a composite value does not
+ change the value, since it means all columns and so the
+ same composite value is produced again. For example,
+ if somefunc() accepts a composite-valued argument,
+ these queries are the same:
+
+SELECT somefunc(c.*) FROM inventory_item c;
+SELECT somefunc(c) FROM inventory_item c;
+
+
+ In both cases, the current row of inventory_item is
+ passed to the function as a single composite-valued argument.
+ Even though .* does nothing in such cases, using it is good
+ style, since it makes clear that a composite value is intended. In
+ particular, the parser will consider c in c.* to
+ refer to a table name or alias, not to a column name, so that there is
+ no ambiguity; whereas without .*, it is not clear
+ whether c means a table name or a column name, and in fact
+ the column-name interpretation will be preferred if there is a column
+ named c.
+
+
+ Another example demonstrating these concepts is that all these queries
+ mean the same thing:
+SELECT * FROM inventory_item c ORDER BY c;
+SELECT * FROM inventory_item c ORDER BY c.*;
+SELECT * FROM inventory_item c ORDER BY ROW(c.*);
+
+ All of these ORDER BY clauses specify the row's composite
+ value, resulting in sorting the rows according to the rules described
+ in . However,
+ if inventory_item contained a column
+ named c, the first case would be different from the
+ others, as it would mean to sort by that column only. Given the column
+ names previously shown, these queries are also equivalent to those above:
+SELECT * FROM inventory_item c ORDER BY ROW(c.name, c.supplier_id, c.price);
+SELECT * FROM inventory_item c ORDER BY (c.name, c.supplier_id, c.price);
+
+ (The last case uses a row constructor with the key word ROW
+ omitted.)
+
+
+ Another special syntactical behavior associated with composite values is
+ that we can use functional notation for extracting a field
+ of a composite value. The simple way to explain this is that
+ the notations field(table)
+ and table.field
+ are interchangeable. For example, these queries are equivalent:
+
+SELECT c.name FROM inventory_item c WHERE c.price > 1000;
+SELECT name(c) FROM inventory_item c WHERE price(c) > 1000;
+
+
+ Moreover, if we have a function that accepts a single argument of a
+ composite type, we can call it with either notation. These queries are
+ all equivalent:
+
+SELECT somefunc(c) FROM inventory_item c;
+SELECT somefunc(c.*) FROM inventory_item c;
+SELECT c.somefunc FROM inventory_item c;
+
+
+
+ This equivalence between functional notation and field notation
+ makes it possible to use functions on composite types to implement
+ computed fields.
+
+
+
+ computed
+
+ An application using the last query above wouldn't need to be directly
+ aware that somefunc isn't a real column of the table.
+
+
+
+ Because of this behavior, it's unwise to give a function that takes a
+ single composite-type argument the same name as any of the fields of
+ that composite type. If there is ambiguity, the field-name
+ interpretation will be preferred, so that such a function could not be
+ called without tricks. One way to force the function interpretation is
+ to schema-qualify the function name, that is, write
+ schema.func(compositevalue).
+
+
+
+
Composite Type Input and Output Syntax
projects / postgresql.git / commitdiff