Re: create or replace view

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Scott Shattuck <ss(at)technicalpursuit(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: create or replace view
Date: 2002-11-14 20:01:49
Message-ID: 20021114114413.H97158-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. :)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross J. Reedstrom 2002-11-14 20:09:01 Re: Propose RC1 for Friday ...
Previous Message Tom Lane 2002-11-14 19:35:37 Re: pg_dump in 7.4