
>Yes (and I agree that it would be a good feature), but that will still
>require full client side parsing of the code to figure out the dependencies
>- I for one, do not wish to try to recreate (and keep up-to-date) the
>PostgreSQL parser in VB. Besides which, if we take it that far then we might
>just as well use reverse engineered SQL to scan for dependencies. I know you
>don't like reverse engineered code, but bear in mind that the important bits
>are reported directly from PostgreSQL (e.g. pg_proc.prosrc).

IMHO view modification can be achieved within one transaction, without 
development table nor PL/pgSQL.

Could you give me your feedback again for view modification:
- Attempt to create a view with the new definition to ensure it's valid.
- Open transaction (in locking mode as we may drop triggers in many tables).
- Drop dependent views in OID order. Keep CREATE SQL strings for future usage.
- Drop dependent triggers. Keep CREATE SQL strings for future usage.
- Drop dependent rules. Keep CREATE SQL strings for future usage.
- Drop the old view and create the new view.
- Create dependent views, triggers and rules.
- Re-apply any comments and ACLs.
- Commit transaction.
- Query pg_class for the updated OID.

This would allow migration from pgAdmin I to pgAdmin II.

/Later,
Jean-Michel

Tue, 30 Oct 2001 11:38:48 +0100
Jean-Michel POURE <jm.poure@freesurf.fr>
Re: DROP/CREATE