[DOCS] Undocumented trick in SELECT?
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
Re: [DOCS] Undocumented trick in SELECT?
=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= 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 -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Re: [COMMITTERS] pgsql: Remove unnecessary xref endterm attributes and title ids The
On lör, 2010-04-03 at 11:15 -0400, Tom Lane wrote: > > Remove unnecessary xref endterm attributes and title ids > > > The endterm attribute is mainly useful when the toolchain does not support > > automatic link target text generation for a particular situation. In the > > past, this was required by the man page tools for all reference page links, > > but that is no longer the case, and it now actually gets in the way of > > proper automatic link text generation. The only remaining use cases are > > currently xrefs to refsects. > > I won't miss the need to write endterm, but what's the "remaining use > cases" exactly? You need to explain to other people what's the new > dispensation, if you don't want it to get messed up again. Right, the upshot is that if the toolchain complains like this openjade:indices.sgml:101:28:E: [xref to REFSECT2 unsupported] then it means it cannot create a linkend text automatically and you need to supply the endterm attribute to tell it what text to use. If it doesn't complain, endterm should probably not be used. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
