database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-30 06:01:21 +03:00
Code Activity

Recognize functional dependency on primary keys. This allows a table's

Browse Source 
other columns to be referenced without listing them in GROUP BY, so long as
the primary key column(s) are listed in GROUP BY.

Eventually we should also allow functional dependency on a UNIQUE constraint
when the columns are marked NOT NULL, but that has to wait until NOT NULL
constraints are represented in pg_constraint, because we need to have
pg_constraint OIDs for all the conditions needed to ensure functional
dependency.

Peter Eisentraut, reviewed by Alex Hunsaker and Tom Lane
This commit is contained in:
Tom Lane
2010-08-07 02:44:09 +00:00
parent ce6ce1a09d
commit e49ae8d3bc
16 changed files with 684 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
doc/src/sgml/queries.sgml
View File

@@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.58 2010/07/03 02:57:46 rhaas Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.59 2010/08/07 02:44:05 tgl Exp $ -->
<chapter id="queries">
<title>Queries</title>
@@ -886,10 +886,7 @@ SELECT product_id, p.name, (sum(s.units) * p.price) AS sales
In this example, the columns <literal>product_id</literal>,
<literal>p.name</literal>, and <literal>p.price</literal> must be
in the <literal>GROUP BY</> clause since they are referenced in
the query select list. (Depending on how the products
table is set up, name and price might be fully dependent on the
product ID, so the additional groupings could theoretically be
unnecessary, though this is not implemented.) The column
the query select list (but see below). The column
<literal>s.units</> does not have to be in the <literal>GROUP
BY</> list since it is only used in an aggregate expression
(<literal>sum(...)</literal>), which represents the sales
@@ -897,6 +894,18 @@ SELECT product_id, p.name, (sum(s.units) * p.price) AS sales
all sales of the product.
</para>
<para>
If the products table is set up so that,
say, <literal>product_id</literal> is the primary key, then it
would be enough to group by <literal>product_id</literal> in the
above example, since name and price would
be <firstterm>functionally
dependent</firstterm><indexterm><primary>functional
dependency</primary></indexterm> on the product ID, and so there
would be no ambiguity about which name and price value to return
for each product ID group.
</para>
<para>
In strict SQL, <literal>GROUP BY</> can only group by columns of
the source table but <productname>PostgreSQL</productname> extends