zero-column table behavior - Mailing list pgsql-hackers

From Neil Conway
Subject zero-column table behavior
Date
Msg-id 40AFF03B.7030304@samurai.com
Whole thread Raw
Responses Re: zero-column table behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: zero-column table behavior  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-hackers
Does the following zero-column behavior strike anyone else as being a 
little strange? I can take a look at fixing this, I'm just curious if 
there's a consensus that the status quo isn't optimal.

(1)

neilc=# create table zero_col ();
CREATE TABLE
neilc=# select * from zero_col;

--
(0 rows)

-- Why is there a blank line before the "--" that indicates the
-- end of the result set? That seems inconsistent with the way
-- we present a normal empty result set:

neilc=# create table abc (a int);
CREATE TABLE
neilc=# select * from abc; a
---
(0 rows)

(2)

neilc=# insert into zero_col default values;
INSERT 17218 1
neilc=# insert into zero_col default values;
INSERT 17219 1
neilc=# select * from zero_col;

--
(2 rows)

-- If the result set contains two rows, ISTM the psql output
-- should emit either two or three blank lines before the "--"
-- that indicates the end of the result set

(3)

neilc=# select * from zero_col order by random();
ERROR:  ORDER/GROUP BY expression not found in targetlist

-- ISTM that ought to work

(4)

neilc=# create view zero_col_view as select * from zero_col;
ERROR:  view must have at least one column

-- ISTM that ought to work as well: if we allow zero-column tables,
-- is there a good reason for disallowing zero-column views?

-Neil



pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: New horology failure
Next
From: Tom Lane
Date:
Subject: Re: CVS HEAD: "make install" broken for vpath