On Fri, Oct 28, 2011 at 11:47 AM, pg noob <pgnube@gmail.com> wrote:
>
> Thank you. That approach looks promising.
> When you say that it is not side effect free, are there any other side
> effects other than the composite types one you mentioned?
> I don't believe these tables contain any composite types so it shouldn't be
> an issue.
>
> I tested it and found that there is no ALTER TABLE <foo> RENAME to <bar>
> CASCADE.
whoops -- the CASCADE was supposed to be after the DROP TABLE.
> Where this approach seems to break down is when the table has a lot of
> dependent objects (dependent constraints, functions, views, triggers, etc.).
> I could use DROP CASCADE but then I would also need to save and recreate all
> those dependent objects as well.
>
> But for simple tables that don't have a lot of dependent objects your
> suggested approach seems like it can work well.
correct -- you have to rebuild all that stuff. if you structure your
code properly though, that should be pretty doable. again though -- a
partitioning strategy might be the best way to go long term though.
merlin
