|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.35 2006/02/18 23:14:45 neilc Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.36 2006/09/18 19:54:01 tgl Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="queries">
|
4 | 4 | <title>Queries</title>
|
@@ -104,7 +104,7 @@ SELECT random();
|
104 | 104 | produce a virtual table that provides the rows that are passed to
|
105 | 105 | the select list to compute the output rows of the query.
|
106 | 106 | </para>
|
107 |
| - |
| 107 | + |
108 | 108 | <sect2 id="queries-from">
|
109 | 109 | <title>The <literal>FROM</literal> Clause</title>
|
110 | 110 |
|
@@ -253,12 +253,12 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
|
253 | 253 |
|
254 | 254 | <para>
|
255 | 255 | <indexterm>
|
256 |
| - <primary>join</primary> |
257 |
| - <secondary>natural</secondary> |
258 |
| - </indexterm> |
| 256 | + <primary>join</primary> |
| 257 | + <secondary>natural</secondary> |
| 258 | + </indexterm> |
259 | 259 | <indexterm>
|
260 |
| - <primary>natural join</primary> |
261 |
| - </indexterm> |
| 260 | + <primary>natural join</primary> |
| 261 | + </indexterm> |
262 | 262 | Finally, <literal>NATURAL</> is a shorthand form of
|
263 | 263 | <literal>USING</>: it forms a <literal>USING</> list
|
264 | 264 | consisting of exactly those column names that appear in both
|
@@ -511,33 +511,36 @@ SELECT * FROM some_very_long_table_name s JOIN another_fairly_long_name a ON s.i
|
511 | 511 | <programlisting>
|
512 | 512 | SELECT * FROM my_table AS m WHERE my_table.a > 5;
|
513 | 513 | </programlisting>
|
514 |
| - is not valid SQL syntax. What will actually happen (this is a |
515 |
| - <productname>PostgreSQL</productname> extension to the standard) |
516 |
| - is that an implicit table reference is added to the |
| 514 | + is not valid according to the SQL standard. In |
| 515 | + <productname>PostgreSQL</productname> this will draw an error if the |
| 516 | + <xref linkend="guc-add-missing-from"> configuration variable is |
| 517 | + <literal>off</>. If it is <literal>on</>, an implicit table reference |
| 518 | + will be added to the |
517 | 519 | <literal>FROM</literal> clause, so the query is processed as if
|
518 | 520 | it were written as
|
519 | 521 | <programlisting>
|
520 | 522 | SELECT * FROM my_table AS m, my_table AS my_table WHERE my_table.a > 5;
|
521 | 523 | </programlisting>
|
522 |
| - which will result in a cross join, which is usually not what you |
523 |
| - want. |
| 524 | + That will result in a cross join, which is usually not what you want. |
524 | 525 | </para>
|
525 | 526 |
|
526 | 527 | <para>
|
527 | 528 | Table aliases are mainly for notational convenience, but it is
|
528 | 529 | necessary to use them when joining a table to itself, e.g.,
|
529 | 530 | <programlisting>
|
530 |
| -SELECT * FROM my_table AS a CROSS JOIN my_table AS b ... |
| 531 | +SELECT * FROM people AS mother JOIN people AS child ON mother.id = child.mother_id; |
531 | 532 | </programlisting>
|
532 | 533 | Additionally, an alias is required if the table reference is a
|
533 | 534 | subquery (see <xref linkend="queries-subqueries">).
|
534 | 535 | </para>
|
535 | 536 |
|
536 | 537 | <para>
|
537 |
| - Parentheses are used to resolve ambiguities. The following |
538 |
| - statement will assign the alias <literal>b</literal> to the |
539 |
| - result of the join, unlike the previous example: |
| 538 | + Parentheses are used to resolve ambiguities. In the following example, |
| 539 | + the first statement assigns the alias <literal>b</literal> to the second |
| 540 | + instance of <literal>my_table</>, but the second statement assigns the |
| 541 | + alias to the result of the join: |
540 | 542 | <programlisting>
|
| 543 | +SELECT * FROM my_table AS a CROSS JOIN my_table AS b ... |
541 | 544 | SELECT * FROM (my_table AS a CROSS JOIN my_table) AS b ...
|
542 | 545 | </programlisting>
|
543 | 546 | </para>
|
@@ -592,6 +595,17 @@ FROM (SELECT * FROM table1) AS alias_name
|
592 | 595 | reduced to a plain join, arise when the subquery involves
|
593 | 596 | grouping or aggregation.
|
594 | 597 | </para>
|
| 598 | + |
| 599 | + <para> |
| 600 | + A subquery can also be a <command>VALUES</> list: |
| 601 | +<programlisting> |
| 602 | +FROM (VALUES ('anne', 'smith'), ('bob', 'jones'), ('joe', 'blow')) |
| 603 | + AS names(first, last) |
| 604 | +</programlisting> |
| 605 | + Again, a table alias is required. Assigning alias names to the columns |
| 606 | + of the <command>VALUES</> list is optional, but is good practice. |
| 607 | + For more information see <xref linkend="queries-values">. |
| 608 | + </para> |
595 | 609 | </sect3>
|
596 | 610 |
|
597 | 611 | <sect3 id="queries-tablefunctions">
|
@@ -814,7 +828,7 @@ SELECT <replaceable>select_list</replaceable>
|
814 | 828 | (3 rows)
|
815 | 829 | </screen>
|
816 | 830 | </para>
|
817 |
| - |
| 831 | + |
818 | 832 | <para>
|
819 | 833 | In the second query, we could not have written <literal>SELECT *
|
820 | 834 | FROM test1 GROUP BY x</literal>, because there is no single value
|
@@ -1194,7 +1208,7 @@ SELECT DISTINCT ON (<replaceable>expression</replaceable> <optional>, <replaceab
|
1194 | 1208 | <indexterm zone="queries-order">
|
1195 | 1209 | <primary>ORDER BY</primary>
|
1196 | 1210 | </indexterm>
|
1197 |
| - |
| 1211 | + |
1198 | 1212 | <para>
|
1199 | 1213 | After a query has produced an output table (after the select list
|
1200 | 1214 | has been processed) it can optionally be sorted. If sorting is not
|
@@ -1335,4 +1349,74 @@ SELECT <replaceable>select_list</replaceable>
|
1335 | 1349 | </para>
|
1336 | 1350 | </sect1>
|
1337 | 1351 |
|
| 1352 | + |
| 1353 | + <sect1 id="queries-values"> |
| 1354 | + <title><literal>VALUES</literal> Lists</title> |
| 1355 | + |
| 1356 | + <indexterm zone="queries-values"> |
| 1357 | + <primary>VALUES</primary> |
| 1358 | + </indexterm> |
| 1359 | + |
| 1360 | + <para> |
| 1361 | + <literal>VALUES</> provides a way to generate a <quote>constant table</> |
| 1362 | + that can be used in a query without having to actually create and populate |
| 1363 | + a table on-disk. The syntax is |
| 1364 | +<synopsis> |
| 1365 | +VALUES ( <replaceable class="PARAMETER">expression</replaceable> [, ...] ) [, ...] |
| 1366 | +</synopsis> |
| 1367 | + Each parenthesized list of expressions generates a row in the table. |
| 1368 | + The lists must all have the same number of elements (i.e., the number |
| 1369 | + of columns in the table), and corresponding entries in each list must |
| 1370 | + have compatible datatypes. The actual datatype assigned to each column |
| 1371 | + of the result is determined using the same rules as for <literal>UNION</> |
| 1372 | + (see <xref linkend="typeconv-union-case">). |
| 1373 | + </para> |
| 1374 | + |
| 1375 | + <para> |
| 1376 | + As an example, |
| 1377 | + |
| 1378 | +<programlisting> |
| 1379 | +VALUES (1, 'one'), (2, 'two'), (3, 'three'); |
| 1380 | +</programlisting> |
| 1381 | + |
| 1382 | + will return a table of two columns and three rows. It's effectively |
| 1383 | + equivalent to |
| 1384 | + |
| 1385 | +<programlisting> |
| 1386 | +SELECT 1 AS column1, 'one' AS column2 |
| 1387 | +UNION ALL |
| 1388 | +SELECT 2, 'two' |
| 1389 | +UNION ALL |
| 1390 | +SELECT 3, 'three'; |
| 1391 | +</programlisting> |
| 1392 | + |
| 1393 | + By default, <productname>PostgreSQL</productname> assigns the names |
| 1394 | + <literal>column1</>, <literal>column2</>, etc. to the columns of a |
| 1395 | + <literal>VALUES</> table. The column names are not specified by the |
| 1396 | + SQL standard and different database systems do it differently, so |
| 1397 | + it's usually better to override the default names with a table alias |
| 1398 | + list. |
| 1399 | + </para> |
| 1400 | + |
| 1401 | + <para> |
| 1402 | + Syntactically, <literal>VALUES</> followed by expression lists is |
| 1403 | + treated as equivalent to |
| 1404 | +<synopsis> |
| 1405 | +SELECT <replaceable>select_list</replaceable> FROM <replaceable>table_expression</replaceable> |
| 1406 | +</synopsis> |
| 1407 | + and can appear anywhere a <literal>SELECT</> can. For example, you can |
| 1408 | + use it as an arm of a <literal>UNION</>, or attach a |
| 1409 | + <replaceable>sort_specification</replaceable> (<literal>ORDER BY</>, |
| 1410 | + <literal>LIMIT</>, and/or <literal>OFFSET</>) to it. <literal>VALUES</> |
| 1411 | + is most commonly used as the data source in an <command>INSERT</> command, |
| 1412 | + and next most commonly as a subquery. |
| 1413 | + </para> |
| 1414 | + |
| 1415 | + <para> |
| 1416 | + For more information see <xref linkend="sql-values" |
| 1417 | + endterm="sql-values-title">. |
| 1418 | + </para> |
| 1419 | + |
| 1420 | + </sect1> |
| 1421 | + |
1338 | 1422 | </chapter>
|
0 commit comments