playing with catalog tables limits? dangers? was: seq bug 2073 and time machine - Mailing list pgsql-general

From Ivan Sergio Borgonovo
Subject playing with catalog tables limits? dangers? was: seq bug 2073 and time machine
Date
Msg-id 20080825091438.27ff9c7d@dawn.webthatworks.it
Whole thread Raw
In response to Re: seq bug 2073 and time machine  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: playing with catalog tables limits? dangers? was: seq bug 2073 and time machine
List pgsql-general
On Sun, 24 Aug 2008 17:26:24 -0400
Alvaro Herrera <alvherre@commandprompt.com> wrote:

> Ivan Sergio Borgonovo wrote:
> > I was trying to drop a serial.
> > Dropped the default for a column.
> > Now it seems I can't drop the sequence since I incurred in:

> > http://archives.postgresql.org/pgsql-bugs/2005-11/msg00304.php

> > Is there a way I can still delete the sequence without using a
> > backup?

> If you're feeling corageous, you can remove the pg_depend entries
> for that sequence.  Make sure to try it in a transaction and drop

I'd like to understand better the risks of being courageous?
I think my life would be easier if I'd know when it is safe to put
hands in the system tables.

> the sequence in that same transaction, so that if you mess up the
> catalogs too badly you can get out of it by rolling back.

Fortunately that pk was referenced just once, so I copied the
content of the table elsewhere, dropped a constraint, dropped the
table and move the content in another one, moved the content back to
a table without serial, recreate the constraint.
Your method is simpler, should be faster and avoid to drop a
constraint but without understanding what's is going to happen
behind the scene it is hard for me to understand if it is safer as
well.

Of course modifying the catalog tables to modify the schema is not
going to be portable across DB... but what about risks and other
limits?

I'm thinking to access the catalog for eg. disabling/dropping a set
of constraint and reenabling/creating them back without the need to
do bookkeeping on the code or writing a script etc...

thanks

--
Ivan Sergio Borgonovo
http://www.webthatworks.it


pgsql-general by date:

Previous
From: Ivan Sergio Borgonovo
Date:
Subject: Re: on delete cascade slowing down delete
Next
From: Brian Green
Date:
Subject: Installing Postgress 8.3.3