Re: Ticket 256: add INSTEAD OF support for triggers

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Ticket 256: add INSTEAD OF support for triggers
Date: 2010-10-23 21:03:45
Message-ID: AANLkTimny1PmR-0=gyi48y7BqQM=iNKwsyOnNsBdiuHv@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

On Sat, Oct 23, 2010 at 3:00 PM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
> Hi,
>
> 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:

bool pgTableObjCollection::CanCreate()
{
// We don't create sub-objects of Views or External tables
if (GetTable()->GetMetaType() == PGM_VIEW ||
GetTable()->GetMetaType() == GP_EXTTABLE)
return false;

return GetSchema()->GetCreatePrivilege();
}

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

and:

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
from Views).

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.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2010-10-23 22:03:29 Re: Ticket 256: add INSTEAD OF support for triggers
Previous Message Guillaume Lelarge 2010-10-23 14:00:37 Ticket 256: add INSTEAD OF support for triggers