Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)
От | David Rowley |
---|---|
Тема | Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b) |
Дата | |
Msg-id | CAApHDvpVUCLBiqOF+eJXwjx0Zeccr7KpYqfW0Ti=cqCTGCP1XA@mail.gmail.com обсуждение исходный текст |
Ответ на | Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b) (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)
|
Список | pgsql-hackers |
On Fri, May 2, 2014 at 3:57 PM, Amit Langote <amitlangote09@gmail.com> wrote:
Hi,
Is the following behavior perceived fix-worthy?
-- note the'1'sin the outputspostgres=# CREATE TABLE test AS SELECT;
SELECT 1postgres=# insert into test select;INSERT 0 1My 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 по дате отправления: