Re: Table modification

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm(dot)poure(at)freesurf(dot)fr]
> Sent: 02 October 2001 10:41
> To: pgadmin-hackers(at)postgresql(dot)org
> Subject: Re: [pgadmin-hackers] Table modification
>
>
>
> >This is the correct way to do it, though I appreciate your
> problem with
> >large tables. Perhaps (for Table objects only) we should have a
> >Tables.DeferRebuild property. When set true, all rebuilds
> triggered by
> >mods of individual properties or collections will get queued
> up until
> >an update method is fired. That way, the update method can
> reduce all
> >the required rebuilds that are queued up into as small an
> operation as
> >possible.
> >
> >What do you think?
> Agreed. Another question: how do we enable table reorganization (i.e.
> change the order of columns)?

Ug. Don't know. I suppose that's a special case (like table/column rename)
where you can't do it any way other than with a special method.

> > > Do I miss something?
> >I don't think so. I would suggest that we both sleep on how
> to achieve
> >the above for a while - in the meantime look at the more simple mods
> >like updating functions/views/triggers.
> Agreed. What are your plans as regards
> functions/views/triggers?
>
Currently I'm working on Revision Control/PostgreSQL 7.2 related updates. I
think it would be fairly easy to implement function/view/trigger
modification *without* project rebuilding. This should be the fisrt step I
think (if someone manually edits such an object they'll still have the same
dependency problems anyway, so they're no worse off!).

> Do you confirm creating objects in
> their OID order should work for solving
> dependencies?

As I said, that's how pg_dump does it afaict. The only case where it (and
pg_dump) fails that I've found so far is illustrated with:

1) Create table with a text column.
2) Create a function that returns a string with no arguments required.
3) Alter the column default to use that function.

The table reload will fail because the function has a higher oid and
therefore is not yet created. pg_dump isn't clever enough to create and
alter later.

Interestingly, if the function is dependant on the table you can create a
cirular dependency.... I don't know how we'd fix that, though I suspect it
might involve Revision Control.

Regards, Dave.