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,

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 по дате отправления:

Предыдущее
От: Ian Barwick
Дата:
Сообщение: pgaudit - an auditing extension for PostgreSQL
Следующее
От: Albe Laurenz
Дата:
Сообщение: Re: Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)