Rozważmy standard SQL, sekcja 7.9 <query specification> jak określono tutaj:
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
<query specification> ::=
SELECT [ <set quantifier> ] <select list> <table expression>
[...]
<select list> ::=
<asterisk>
| <select sublist> [ { <comma> <select sublist> }... ]
[...]
Syntax Rules
1) Let T be the result of the <table expression>.
3) Case:
a) [...]
b) Otherwise, the <select list> "*" is equivalent to a <value
expression> sequence in which each <value expression> is a
<column reference> that references a column of T and each
column of T is referenced exactly once. The columns are ref-
erenced in the ascending sequence of their ordinal position
within T.
Innymi słowy, tak, standard SQL określa, że kolumny mają być rzutowane zgodnie z ich pozycją porządkową w T . Zauważ, że sprawy stają się nieco skomplikowane, gdy <table expression> składa się z kilku tabel zawierających JOIN .. USING lub NATURAL JOIN klauzule. Jednak wybierając z prostej tabeli, prawdopodobnie wszystko w porządku, zakładając, że kolejność jest zgodna z oczekiwaniami.
Dla kompletności, znaczenie ordinal position within T dla tabel wyjaśniono dalej w 11.4 <column definition> :
General Rules
5) [...] The ordinal position included
in the column descriptor is equal to the degree of T. [...]
A potem w 11.11 <add column definition> (dla ALTER TABLE oświadczenia)
General Rules
4) [...] In particular, the degree of T
is increased by 1 and the ordinal position of that column is
equal to the new degree of T as specified in the General Rules
of Subclause 11.4, "<column definition>".
Istnieje wiele innych instrukcji i klauzul SQL, które zależą od formalnej specyfikacji ordinal positions w <table expressions> . Kilka przykładów:
13.8 <insert statement>
(when omitting the `<insert column list>`)
20.2 <direct select statement: multiple rows>
(when `<sort specification>` contains an `<unsigned integer>`)
W szczególności Postgres jest dość zgodny ze standardami, więc jeśli naprawdę chcesz SELECT * , śmiało!
