Thread: Re: [PATCHES] Cascaded Column Drop

Re: [PATCHES] Cascaded Column Drop

From
Tom Lane
Date:
Rod Taylor <rbt@rbt.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


Re: [PATCHES] Cascaded Column Drop

From
Rod Taylor
Date:
On Sat, 2002-09-28 at 16:38, Tom Lane wrote:
> Rod Taylor <rbt@rbt.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;

Which of course would dump as 'create table foo ();'.

I don't think relcache would like a table without any columns, which is
why the above is rejected.


Anyway, should pg_dump ignore the table entirely?  Or do we try to allow
create table () without any attributes?

--  Rod Taylor



Re: [PATCHES] Cascaded Column Drop

From
Tom Lane
Date:
Rod Taylor <rbt@rbt.ca> writes:
>> 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;

> Which of course would dump as 'create table foo ();'.

True.  I didn't say that everything would be happy with it ;-).  I think
that a zero-column table is only useful as a transient state, and so I'm
happy as long as the backend doesn't core dump.

> I don't think relcache would like a table without any columns, which is
> why the above is rejected.

Relcache doesn't seem to have a problem with it.

> Anyway, should pg_dump ignore the table entirely?  Or do we try to allow
> create table () without any attributes?

I feel no strong need to do either.  But it likely would only take
removal of this error check:

regression=# create table foo ();
ERROR:  DefineRelation: please inherit from a relation or define an attribute

at least as far as the backend goes.
        regards, tom lane


Re: [PATCHES] Cascaded Column Drop

From
Rod Taylor
Date:
> regression=# create table foo ();
> ERROR:  DefineRelation: please inherit from a relation or define an attribute
> 
> at least as far as the backend goes.

Found in relcache.c earlier:AssertArg(natts > 0);

Didn't look too hard to see what it protects, because it's more effort
than it's worth.

--  Rod Taylor



Re: [PATCHES] Cascaded Column Drop

From
Tom Lane
Date:
Rod Taylor <rbt@rbt.ca> writes:
> Found in relcache.c earlier:
>     AssertArg(natts > 0);

Okay, one other place to change ... there are probably more such ...
        regards, tom lane