Re: Pseudo alter triggers
От | Dave Page |
---|---|
Тема | Re: Pseudo alter triggers |
Дата | |
Msg-id | FED2B709E3270E4B903EB0175A49BCB1047665@dogbert.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Pseudo alter triggers (Jean-Michel POURE <jm.poure@freesurf.fr>) |
Ответы |
Re: Pseudo alter triggers
|
Список | pgadmin-hackers |
> -----Original Message----- > From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr] > Sent: 04 March 2002 17:04 > To: pgadmin-hackers@postgresql.org > Subject: [pgadmin-hackers] Pseudo alter triggers > > > Dear all, > > I commited a fix to update display after pseudo-altering > triggers. Dave: this > might be ready for review... Hmm, this code is completely inconsistant with the way other properties are modified in pgSchema. Please modify them by using the Property Let code as per normal, not a hacked Alter function. Incidently, changing the table that a trigger is created on has a much deeper impact than I think you realise. Because a trigger is referenced as <trigger> ON <table>, if you change the table then the Identifier property, and hence the key in the Triggers collection must also be changed. This requires code similar to Views.Rename to drop and re-add the object to the collection. Having said that, is it really worth the hassle? I can't see anyone wanting to change the table - you wouldn't change the base table under an Index for example. On another subject.... Some time ago we discussed your new style of SQL property - I stated that I could see what you wanted to achive, but wasn't happy that the exported API was becoming messy - especially where you have added code that isn't being used yet (and may not ever be). I propose the following compromise: Whereever required, create an iSQL (internal SQL) Friend property. This (being declared Friend) will only be visible inside pgSchema. This property will accept the arguments you wish to include to drop and change the object as required. These facilities should *never* be available outside pgSchema anyway as any application should use the normal Property Let/Get's. For the public API, the existing SQL property should be used. It in turn can use the iSQL code with the relevant options. e.g. Friend Property Get iSQL(bDrop As Boolean, Optional szNewName as String) As String If bDrop Then szSQL = "DROP ..." szSQL = szSQL & "CREATE ..." iSQL = szSQL End Property Public Property SQL() As String SQL = iSQL(False) End Property Best of both worlds I think, what about you? Regards, Dave.
В списке pgadmin-hackers по дате отправления: