Hello all,
> >And the answer is "no, you can't". Recreate the table with correct types
> >and insert the old values into it.
>
>You're kidding me, right? *prepares to gargle* MS Sql server can. Surely
>we can implement this feature or aren't we aiming to go head to head with
>commercial rdbms'?
The other day, I spent 3 hours dropping old_1, old_2 and old_n fields in a DB.
But what if your table if it has triggers or foreign keys.
There is a very similar problem with DROP FUNCTION / CREATE FUNCTION.
If function A is based on function B and you drop function B, function A is
broken.
Same as for views: if view A incorporates function A and you drop function
A, view A is broken.
OK: what's the point then?
THE POINT IS THAT WHEN YOU HAVE NESTED OBJECTS, YOU NEED TO DROP THEM ALL
AND RECREATE THEM ALL.
SO IF YOU WANT TO MODIFY ONE LINE OF CODE, YOU WILL PROBABLY NEED TO
REBUILD ANYTHING.
NORMAL HUMANS CANNOT DO THIS. MY CODE IS COMPLETE POSTGRESQL SERVER-SIDE.
IN THESE CONDITIONS, THE CODE CANNOT BE OPTIMIZED ALSO BECAUSE OIDs CHANGE
ALL THE TIME.
The way we do it in pgAdmin I
http://cvs.social-housing.org/viewcvs.cgi/pgadmin1
is that we maintain a dependency table based on STRING NAMES and not OIDs.
When altering an object (view, function, trigger) we rebuild all dependent
objects.
Is this the way we should proceed with pgAdmin II?
Is anyone planning a real dependency table based on object STRING NAMES?
We need some advice:
1) Client solution: should we add the rebuilding feature to pgAdmin II?
2) Server solution: should we wait until the ALTER OBJECT project is complete?
Please advice. Help needed.
Vote for (1) or (2).
Regards,
Jean-Michel POURE
pgAdmin Team
http://pgadmin.postgresql.org