Обсуждение: Pseudo alter triggers

Поиск
Список
Период
Сортировка

Pseudo alter triggers

От
Jean-Michel POURE
Дата:
Dear all,

I commited a fix to update display after pseudo-altering triggers. Dave: this
might be ready for review...

Cheers,
Jean-Michel

Re: Pseudo alter triggers

От
Dave Page
Дата:

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


Re: Pseudo alter triggers

От
Jean-Michel POURE
Дата:
Le Lundi 4 Mars 2002 21:33, Dave Page a écrit :
> Best of both worlds I think, what about you?
This seems to be a nice solution my friend.
Cheers, Jean-Michel

Re: Pseudo alter triggers

От
Dave Page
Дата:

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr]
> Sent: 04 March 2002 22:24
> To: Dave Page; pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] Pseudo alter triggers
>
>
> Le Lundi 4 Mars 2002 21:33, Dave Page a écrit :
> > Best of both worlds I think, what about you?
> This seems to be a nice solution my friend.
> Cheers, Jean-Michel

Cool, can you implement it on the Views/Triggers along with your other mods
(perhaps try one first to make sure everyone's happy) and then we can do
others as we get to them?

Cheers, Dave.