Re: create or replace view

On Thursday 14 November 2002 08:01 pm, Stephan Szabo wrote:
> On Thu, 14 Nov 2002, Scott Shattuck wrote:
> > It might just be me but it seems that this discussion is missing the
> > point if we believe this request is about saving some characters. I
> > don't think it is. I think it's about being able to write simple SQL
> > scripts that don't produce errors when you use the syntax below in an
> > adminstration or development script and the object doesn't exist:
>
> I think there are two groups of people who have different ideas of what
> this functionality is supposed to do. From my understanding of the
> discussions on create or replace function, the point really was to do an
> in place modification to not need to drop and recreate dependent objects.
> Note that afaik you also can't change the return type of a function in a
> create or replace if it already exists with a different return type.
>
> The other usage is useful, but I don't think it was the intended way to be
> used. I use it that way too, but if I get an error on a create or replace
> I do the more involved version (dump dependents if necessary, drop
> cascade, create, edit dump, restore).
>
> > If we're concerned with this change from a consistency perspective, look
> > at triggers. The programmer drops a function and the triggers relying on
> > that function go to hell. Sure, and if we said "you can't drop the
> > function because triggers might break" then it'd parallel what we're
> > saying here -- in effect "we know better than you do what you want". Or
> > to use M$ terminology "we know where you want to go today" ;).
>
> In fact, afaict 7.3 does exactly this unless you use drop cascade.
> I don't think that the past way was particularly easier, with needing to
> dump/restore dependent objects in order to make them work again. I think
> of it like constraints, as much as you can you enforce the constraint.
> It's possible that the next statement will make the sequence
> work for the constraint, but you don't wait to find out.
>
> > B. We want to treat people who are interested in PostgreSQL with respect
> > at all times, keeping in mind that we communicate with them not only
> > through this forum, but through the code we write for them.
>
> This is always true. Even if we forget sometimes. :)
>
>
Problem is when I want change view (or functions) with a lot of dependecies
I must drop and recreate all dependent views (or functions) - I want add only
one column in view
I don't know if solution hard for that.

regards
Haris Peco