From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Zhang Mingli <zmlpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SELECT INTO without columns or star |
Date: | 2023-03-31 15:26:24 |
Message-ID: | 555908.1680276384@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Fri, Mar 31, 2023 at 8:10 AM Zhang Mingli <zmlpostgres(at)gmail(dot)com> wrote:
>> When I exec a sql SELECT INTO without columns or * by mistake, it succeeds:
> Yes, a table may have zero columns by design.
Yup, we've allowed that for some time now; see the compatibility comments
at the bottom of the SELECT man page.
psql's display of zero-column results is a bit weird, which maybe
somebody should fix sometime:
regression=# select from generate_series(1,4);
--
(4 rows)
I'd expect four blank lines there. Expanded format is even less sane:
regression=# \x
Expanded display is on.
regression=# select from generate_series(1,4);
(4 rows)
ISTM that should produce
[ RECORD 1 ]
[ RECORD 2 ]
[ RECORD 3 ]
[ RECORD 4 ]
and no "(4 rows)" footer, because \x mode doesn't normally print that.
This is all just cosmetic of course, but it's still confusing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-03-31 16:15:33 | Re: regression coverage gaps for gist and hash indexes |
Previous Message | David G. Johnston | 2023-03-31 15:13:28 | Re: SELECT INTO without columns or star |