On Sat, Oct 23, 2010 at 3:00 PM, Guillaume Lelarge
> It was much easier than I previously thought. This patch adds a Triggers
> node in the each view object node if you're connected to a 9.1
> PostgreSQL server. You can add and see triggers on views.
> It's not ready to be commited. I still have a bug to fix. I tried since
> two days, and I can't make it work. My issue is with the Triggers node.
> I should have the "Create a new object..." button enabled in the toolbar
> and a "New trigger" (or whatever it's labelled) item in the contextual
> menu. But I don't have them. I really don't understand why. View objects
> seem to be treated differently than others but, despite many tests, I
> can't make it work.
> You can still test the patch because you have the capacity to create a
> trigger on a view with a contextual menu available on the view object node.
> If someone has a pointer to help me fix this patch, I would really
> appreciate it.
I believe this is the source of your trouble:
// We don't create sub-objects of Views or External tables
if (GetTable()->GetMetaType() == PGM_VIEW ||
GetTable()->GetMetaType() == GP_EXTTABLE)
This is related to some extreme weirdness that should have been
properly commented when it was written, but alas wasn't, probably
because it all seemed quite sensible at the time. As you know, the
various object classes are all derived from a higher level parent
class - eg. pgDatabase is derived from pgServerObject,
pgSchema/pgCatalog are derived from pgDatabaseObject (via
pgSchemaBase) and so-on. This gets weird with Rules, which are
sub-objects of both tables and views:
pgTable derives from pgSchemaObject
pgView derives from pgSchemaObject
pgColumn derives from pgTableObject
pgRule derives from pgRuleObject
pgRuleObject derives from pgSchemaObject
If memory serves, pgRuleObject exists as a generic parent class to
allow a rule to be a fully functional child of both a table and a view
(this isn't required for a column, as you cannot add or remove them
My guess is to do this properly you'll probably have to create a
similar pgTriggerObject class (or make pgRuleObject into a more
generic pgRelationObject), and then add properties to represent the
table/view directly to pgTrigger and re-parent it appropriately.
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
In response to
pgadmin-hackers by date
|Next:||From: Guillaume Lelarge||Date: 2010-10-23 22:03:29|
|Subject: Re: Ticket 256: add INSTEAD OF support for triggers|
|Previous:||From: Guillaume Lelarge||Date: 2010-10-23 14:00:37|
|Subject: Ticket 256: add INSTEAD OF support for triggers|