Re: [PATCHES] Cascaded Column Drop

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rod Taylor <rbt(at)rbt(dot)ca>
Cc: "Tim Knowles" <tim(at)ametco(dot)co(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [PATCHES] Cascaded Column Drop
Date: 2002-09-28 20:38:29
Message-ID: 4644.1033245509@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Rod Taylor <rbt(at)rbt(dot)ca> writes:
> Leaving a zero-width table would be best, even if its not so useful. I
> don't like rejecting a CASCADE as it kinda defeats the purpose of having
> CASCADE.

I did something about this --- as of CVS tip, you can do

regression=# create table foo (f1 int);
CREATE TABLE
regression=# alter table foo drop column f1;
ALTER TABLE
regression=# select * from foo;

--
(0 rows)

I fixed the places that were exposed by the regression tests as not
coping with zero-column tables, but it is likely that there are some
more places that will give odd errors with such a table. Feel free
to beat on it.

psql seems to have some minor issues with a zero-column select.
You can do this:

regression=# insert into foo default values;
INSERT 720976 1
regression=# select * from foo;

--
(1 row)

regression=# insert into foo default values;
INSERT 720977 1
regression=# select * from foo;

--
(2 rows)

regression=#

Seems like nothing's being printed for an empty row.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Manfred Koizar 2002-09-28 20:38:43 Re: Bug in PL/pgSQL GET DIAGNOSTICS?
Previous Message Marc G. Fournier 2002-09-28 20:24:43 Re: v7.3 Branched ...

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2002-09-29 00:06:04 Re: DROP COLUMN misbehaviour with multiple inheritance
Previous Message Alvaro Herrera 2002-09-28 19:44:02 Re: [HACKERS] pg_dump and inherited attributes