>Yes, I agree. As I said in my first message, there is no problem with
>standalone views, but (and this is the killer) if your view is a dependency
>of something else like an SQL function or another view then you have a
>problem. The problem is even bigger (i.e. harder to detect) if the rowtype
>of the view is used as a parameter to or return value from a function (is
>this actually possible? I know it is with a table).
Yes, it is possible, but functions treat views and table as SQL.
Remember, I learnt it from you !!! No dependency problem.
Ex: Create table1. Create function1 that outputs a value from table1.
Drop table1. Create table1. Run function1. It should work.
Needs some testing to verify.
> > Could you give me your feedback again for view modification:
> > - Attempt to create a view with the new definition to ensure
> > it's valid.
>
>Yes.
>
> > - Open transaction (in locking mode as we may drop triggers
> > in many tables).
>
>Yes.
>
> > - Drop dependent views in OID order. Keep CREATE SQL strings
> > for future usage.
>
>Yes.
>
> > - Drop dependent triggers. Keep CREATE SQL strings for future usage.
>
>Can triggers be dependent on views?
>
> > - Drop dependent rules. Keep CREATE SQL strings for future usage.
>
>Yes.
>
> > - Drop the old view and create the new view.
>
>Yes.
>
> > - Create dependent views, triggers and rules.
>
>Yes.
>
> > - Re-apply any comments and ACLs.
>
>Yes.
>
> > - Commit transaction.
>I wouldn't be surprised if some of these actions are not 'transactionable'.
>Things like create user/database for example definitely aren't.
I did not think of it. You are right.
>Incidently, pgAdmin II (and pgSchema) has no concept of objects being
>defined on Views at present. I'll add that to my To-Do list - presumable
>it's only Rules (and Triggers?).
Triggers for 100% sure. We could automate the creation of triggers for view
updating/deleting.
Highly wanted cool feature.
Cheers,
Jean-Michel
