From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | Kevin Brannen <KBrannen(at)efji(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SELECT INTO question |
Date: | 2019-07-25 19:47:26 |
Message-ID: | 31985.1564084046@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
> On 7/25/19 12:23 PM, Kevin Brannen wrote:
>> We're trying to understand what happened with a SELECT INTO. The problem
>> can be see with this example:
>>
>> nms=# select into t2 from t1;
>> SELECT 5
>> # select * from t2;
>> --
>> (5 rows)
> The list of output expressions after SELECT can be empty, producing a
> zero-column result table. This is not valid syntax according to the SQL
> standard. PostgreSQL allows it to be consistent with allowing
> zero-column tables. However, an empty list is not allowed when DISTINCT
> is used.
Right, you selected no columns from t1, so t2 has no columns (and yet
five rows). Worth noting here is that psql is a bit squirrely about
displaying zero-column results --- it drops the column-names header
line, and it doesn't emit a blank-line-per-row as one might expect.
Perhaps somebody ought to fix that, but it's such a corner case that
no one has bothered yet.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Brannen | 2019-07-25 19:52:42 | RE: SELECT INTO question |
Previous Message | Adrian Klaver | 2019-07-25 19:39:16 | Re: postgres 9.5 DB corruption |