Le Dimanche 11 Août 2002 17:53, Tom Lane a écrit :
> Hmm. I remember Poure asking repeatedly for CREATE OR REPLACE VIEW,
> and that makes a lot of sense to me, because other things *can* depend
> on a view. (Unfortunately, by the same token it's a lot harder to do.)
> The use-case for replacing a trigger is not visible to the naked eye.
Dear Tom,
Replacing a trigger is interesting, for several reasons:
- you may need to temporary disable a trigger. In pgAdmin2, you may move the
view to a temporary table. This can be done by other means, but none is
standard. By the way, a DISSABLE TRIGGER would be usefull.
- you may need to choose another function or change events.
- systems with server-side code need to be UPGRADED. Look at Compiere for
example. When the database schema evolves, a scripts shall be able to run
server-side and upgrade the database safely.
- newbees like to play around just as if they were in Access, Excel or MySQL.
In pgAdmin2, the graphical presentation enables them to create, move, alter
and delete objects. This is very important for someone who learns databases.
Learning becomes a game.
Inside PostgreSQL backend, I see no reason why this should not be done by a
DROP/CREATE.
Last of all, if all objects could be REPLACED or ALTERED inside PostgreSQL, it
would become interesting to create automatic Diff between revisions of a
schema. Then, PostgreSQL itself sould be able to write the upgrade script.
What do you think of this advanced feature?
Do you think it is possible to store schema dumps inside postgreSQL and
generate upgrade scripts between revisions?
Cheers,
Jean-Michel