Undocumented trick in SELECT?

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