Re: [HACKERS] [PATCHES] Cascaded Column Drop
Rod Taylor <[EMAIL PROTECTED]> writes: > Found in relcache.c earlier: > AssertArg(natts > 0); Okay, one other place to change ... there are probably more such ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Cascaded Column Drop
> 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] Cascaded Column Drop
Rod Taylor <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Cascaded Column Drop
On Sat, 2002-09-28 at 16:38, Tom Lane wrote: > Rod Taylor <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] Cascaded Column Drop
Rod Taylor <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html