Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgadmin-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group