Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)
Date: 2014-05-02 07:14:12
Message-ID: CAApHDvpVUCLBiqOF+eJXwjx0Zeccr7KpYqfW0Ti=cqCTGCP1XA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 2, 2014 at 3:57 PM, Amit Langote <amitlangote09(at)gmail(dot)com>wrote:

>
> Hi,
>
> I
> ​s the following behavior perceived fix-worthy?
>
>
> -- note the
> ​'​
> ​1's
> in the output
> ​s
> ​
>
> ​po​
> stgres=# CREATE TABLE test AS SELECT;
> SELECT 1
>
> postgres=# insert into test select;
> INSERT 0 1​
>
> ​My guess why ​this happens is because changes made in the commit in
> $SUBJECT only pertain to fixing syntax errors and nothing else.
>
>
Are you proposing that this does not insert a 0 column row?

I don't find the current behaviour wrong. If it didn't insert the row then
the query in the following would return 0 rows.

begin work;
create table nocols ();
insert into nocols select;
insert into nocols select;

create table test (value int);
insert into test values(1);

select * from nocols cross join test; -- give 2 rows with the value 1
rollback;

Why should the above results be any different than if I created the nocols
table with a column then dropped it?
Certainly removing all of the records on the drop of the last column would
be wrong.

Regards

David Rowley

--
> Amit
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2014-05-02 07:16:07 Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)
Previous Message Ian Barwick 2014-05-02 06:19:59 pgaudit - an auditing extension for PostgreSQL