Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b) - Mailing list pgsql-hackers

From David Rowley
Subject Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)
Date
Msg-id CAApHDvpVUCLBiqOF+eJXwjx0Zeccr7KpYqfW0Ti=cqCTGCP1XA@mail.gmail.com
Whole thread Raw
In response to Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers

On Fri, May 2, 2014 at 3:57 PM, Amit Langote <amitlangote09@gmail.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

pgsql-hackers by date:

Previous
From: Ian Barwick
Date:
Subject: pgaudit - an auditing extension for PostgreSQL
Next
From: Albe Laurenz
Date:
Subject: Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)