Lists: | pgsql-docs |
---|
From: | Виктор Вислобоков <corochoone(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org> |
Subject: | Undocumented trick in SELECT? |
Date: | 2010-04-04 13:01:28 |
Message-ID: | m2n1f60b6161004040601taa3c3e2cm92789e40864e5ea@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-docs |
I'm sorry, but I have not found such construction into documentation:
SELECT tablename FROM tablename;
http://www.postgresql.org/docs/8.4/static/queries-overview.html
say:
[WITH with_queries] SELECT select_list FROM table_expression
[sort_specification]
http://www.postgresql.org/docs/8.4/static/queries-select-lists.html
say:
"The select list determines which columns of the intermediate table are
actually output."
But, table name is not a column.
Reproduce:
tmp=# create table tmp(id SERIAL, name VARCHAR(10));
NOTICE: CREATE TABLE will create implicit sequence "tmp_id_seq" for serial
column "tmp.id"
CREATE TABLE
tmp=# insert into tmp (name) values('John');
INSERT 0 1
tmp=# insert into tmp (name) values('Pol');
INSERT 0 1
tmp=# insert into tmp (name) values('Martin');
INSERT 0 1
tmp=# select tmp from tmp;
tmp
------------
(1,John)
(2,Pol)
(3,Martin)
(3 rows)
What is this? Is this undocumented or am I bad looked in the documentation?
With best wishes,
Victor Vislobokov
St.Peterburg. Russia
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Виктор Вислобоков <corochoone(at)gmail(dot)com> |
Cc: | PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: Undocumented trick in SELECT? |
Date: | 2010-04-04 16:26:17 |
Message-ID: | 12678.1270398377@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-docs |
=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone(at)gmail(dot)com> writes:
> I'm sorry, but I have not found such construction into documentation:
> SELECT tablename FROM tablename;
It's a whole-row variable. These aren't terribly well documented but you
can find descriptions of them in places. It's not standard SQL --- I
think we inherited it from PostQUEL and kept it because functions on
composite types don't work very well without composite variables.
regards, tom lane