From: | Christos Evaggelou <cevaggelou(at)gmail(dot)com> |
---|---|
To: | pgsql-docs(at)postgresql(dot)org |
Subject: | Suggestion - Document a currently undocumented(?) feature - SELECT Table FROM Table |
Date: | 2016-09-11 08:12:08 |
Message-ID: | CAOToY7hZhQ5q9HOTXPu9tt4g5OtLX51NY-Zh3TmpgyBqritYMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
Hello, wonderful people who are providing us with a wonderful piece of
software!
Just wanted to suggest that an existing feature is included in the
documentation. It seems to be undocumented now. Also I don't think it's an
obvious feature. I looked carefully under the reference section for
SELECT, under the section talking about Composite Types, under the section
talking about ROW() and a bunch of other places but I couldn't find it.
This makes me hesitate to use it, because I don't know if and how much I
can rely on a feature that *seems* undocumented -- by the way, if it *is*
documented somewhere, I apologize in advance.
So, you can use the table name in the SELECT list to pack the columns of
the resultset into a composite datatype matching the table type. For
example, if I have a table called JOB_LOG, I can do this:
testdb=# Select JOB_LOG From JOB_LOG Limit 2;
job_log
--------------------------------------------------------------------------
(1,"2014-08-17 08:32:04.058247","dequeue: Retrieving next pending job",)
(2,"2014-08-17 08:32:04.108799","dequeue: No more jobs",)
(2 rows)
testdb=#
I hope you consider documenting this feature.
Thank you guys. Keep up the good work!
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2016-09-11 10:23:30 | CREATE_REPLICATION_SLOT exported snapshot |
Previous Message | Tom Lane | 2016-09-09 16:39:06 | Re: SET CONSTRAINTS ALL IMMEDIATE affects SET TRANSACTION READ ONLY |