Re: create or replace view

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: create or replace view
Дата
Msg-id 20021114114413.H97158-100000@megazone23.bigpanda.com
обсуждение исходный текст
Ответ на Re: create or replace view  (Scott Shattuck <ss@technicalpursuit.com>)
Ответы Re: create or replace view  (snpe <snpe@snpe.co.yu>)
Список 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. :)




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump in 7.4
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Propose RC1 for Friday ...