Re: Pseudo alter triggers

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: "'jm(dot)poure(at)freesurf(dot)fr'" <jm(dot)poure(at)freesurf(dot)fr>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Pseudo alter triggers
Date: 2002-03-04 20:33:59
Message-ID: FED2B709E3270E4B903EB0175A49BCB1047665@dogbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm(dot)poure(at)freesurf(dot)fr]
> Sent: 04 March 2002 17:04
> To: pgadmin-hackers(at)postgresql(dot)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.

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Jean-Michel POURE 2002-03-04 22:23:58 Re: Pseudo alter triggers
Previous Message Dave Page 2002-03-04 19:48:23 Re: Possible frmMain.tv_NodeClick bug