Обсуждение: CREATE OR REPLACE TRIGGER
Attached is a basic patch implementing create or replace trigger. It passes all regression tests. Gavin
Вложения
Gavin Sherry <swm@linuxworld.com.au> writes:
> Attached is a basic patch implementing create or replace trigger.
Why would we need that, given that we now have CREATE OR REPLACE
FUNCTION? It's not like anything could depend on a trigger
(other than FK constraints, and I don't think I want people replacing
trigger definitions that are part of an FK constraint...)
regards, tom lane
On Sun, 11 Aug 2002, Tom Lane wrote: > Gavin Sherry <swm@linuxworld.com.au> writes: > > Attached is a basic patch implementing create or replace trigger. > > Why would we need that, given that we now have CREATE OR REPLACE > FUNCTION? It's not like anything could depend on a trigger > (other than FK constraints, and I don't think I want people replacing > trigger definitions that are part of an FK constraint...) I thought it conceivable that one may want to point the trigger at a different function, change BEFORE or AFTER, or change the event(s) upon which the trigger fires. Gavin
Gavin Sherry <swm@linuxworld.com.au> writes:
> On Sun, 11 Aug 2002, Tom Lane wrote:
>> Why would we need that, given that we now have CREATE OR REPLACE
>> FUNCTION? It's not like anything could depend on a trigger
>> (other than FK constraints, and I don't think I want people replacing
>> trigger definitions that are part of an FK constraint...)
> I thought it conceivable that one may want to point the trigger at a
> different function, change BEFORE or AFTER, or change the event(s) upon
> which the trigger fires.
But there is no reason you can't just drop and recreate the trigger
to do those things.
Given the lack of popular demand (I don't think I've yet heard anyone
ask for this feature), I can't get excited about expending code bulk
and complexity on it --- the patch seems to make CreateTrigger
significantly messier, and that will cost us in maintenance effort
down the road.
regards, tom lane
On Sun, 11 Aug 2002, Tom Lane wrote: > Gavin Sherry <swm@linuxworld.com.au> writes: > > On Sun, 11 Aug 2002, Tom Lane wrote: > >> Why would we need that, given that we now have CREATE OR REPLACE > >> FUNCTION? It's not like anything could depend on a trigger > >> (other than FK constraints, and I don't think I want people replacing > >> trigger definitions that are part of an FK constraint...) > > > I thought it conceivable that one may want to point the trigger at a > > different function, change BEFORE or AFTER, or change the event(s) upon > > which the trigger fires. > > Given the lack of popular demand (I don't think I've yet heard anyone > ask for this feature), I can't get excited about expending code bulk > and complexity on it --- the patch seems to make CreateTrigger > significantly messier, and that will cost us in maintenance effort > down the road. From memory, I think some of the pgadmin guys jumped up and down about it for a while: http://fts.postgresql.org/db/mw/msg.html?mid=1353289. Gavin
Gavin Sherry <swm@linuxworld.com.au> writes: > From memory, I think some of the pgadmin guys jumped up and down about it > for a while: http://fts.postgresql.org/db/mw/msg.html?mid=1353289. 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. regards, tom lane
On Sun, 11 Aug 2002, Tom Lane wrote: > Gavin Sherry <swm@linuxworld.com.au> writes: > > From memory, I think some of the pgadmin guys jumped up and down about it > > for a while: http://fts.postgresql.org/db/mw/msg.html?mid=1353289. > > 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.) I know. I am finishing off the patch now. > The use-case for replacing a trigger is not visible to the naked eye. That's okay then. I should have thought about it harder. Gavin
> -----Original Message----- > From: Gavin Sherry [mailto:swm@linuxworld.com.au] > Sent: 11 August 2002 17:01 > To: Tom Lane > Cc: pgsql-patches@postgresql.org > Subject: Re: [PATCHES] CREATE OR REPLACE TRIGGER > > > On Sun, 11 Aug 2002, Tom Lane wrote: > > > Gavin Sherry <swm@linuxworld.com.au> writes: > > > From memory, I think some of the pgadmin guys jumped up and down > > > about it for a while: > > > http://fts.postgresql.org/db/mw/msg.html?mid=1353289. > > > > 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.) > > I know. I am finishing off the patch now. > > > The use-case for replacing a trigger is not visible to the > naked eye. > > That's okay then. I should have thought about it harder. It would be nice for pgAdmin 'cos we can then let users alter properties of objects at will. Currently we have a mix of things that can and can't be editted. We often get asked 'why can we do X but not Y in pgAdmin' and then have to explain that it's a PostgreSQL that doesn't allow us to do Y (at least not with some nasty client side hacks that can break dependencies in many cases - admittedly not with a trigger). The more things our users can tweak on the fly, the better imho. Regards, Dave.
"Dave Page" <dpage@vale-housing.co.uk> writes:
>> The use-case for replacing a trigger is not visible to the
>> naked eye.
> It would be nice for pgAdmin 'cos we can then let users alter properties
> of objects at will.
So implement it as DROP TRIGGER/CREATE TRIGGER. There's no need for the
backend to provide a special case shortcut...
regards, tom lane
Le Dimanche 11 Août 2002 21:26, Tom Lane a écrit : > So implement it as DROP TRIGGER/CREATE TRIGGER. There's no need for the > backend to provide a special case shortcut... Please implement DROP/CREATE in the backend. Users do not understand that objects cannot be modified. We all want this feature. We are starving for it... Cheers, Jean-Michel
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
> -----Original Message----- > From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr] > Sent: 13 August 2002 10:26 > To: Tom Lane; Dave Page > Cc: Gavin Sherry; pgsql-patches@postgresql.org > Subject: Re: [PATCHES] CREATE OR REPLACE TRIGGER > > > Le Dimanche 11 Août 2002 21:26, Tom Lane a écrit : > > So implement it as DROP TRIGGER/CREATE TRIGGER. There's no > need for > > the backend to provide a special case shortcut... > > Please implement DROP/CREATE in the backend. Users do not > understand that > objects cannot be modified. We all want this feature. We are > starving for > it... Hi Jean-Michel, Whilst I would rather see this feature in PostgreSQL itself, Tom is right, in this case because nothing is ever dependanton a trigger, a DROP/CREATE in pgAdmin would be relatively easy to implement. At least we should have CREATE OR REPLACE VIEW|RULE which are much harder to do at our end. Regards, Dave.