Re: Ticket 256: add INSTEAD OF support for triggers

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Ticket 256: add INSTEAD OF support for triggers
Date: 2010-10-23 22:03:29
Message-ID: 4CC35BB1.9030100@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Le 23/10/2010 14:03, Dave Page a écrit :
> 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();
> }
>

I believe so too.

> 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

Seems logical.

> pgView derives from pgSchemaObject

Actually, pgView derives from pgRuleObject, which is already weird by
itself but makes the whole thing even more weird.

> pgColumn derives from pgTableObject

Seems logical.

> and:
>
> pgRule derives from pgRuleObject
> pgRuleObject derives from pgSchemaObject

Which just doesn't make sense. I would really like to know the reason of
all this.

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

Yes.

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

Will look into this.

Thanks for your remarks. I hope to come up with something. We'll
probably need someone more knowledgable than me with C++.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2010-10-24 01:30:49 Re: Indonesian and Indonesia
Previous Message Dave Page 2010-10-23 21:03:45 Re: Ticket 256: add INSTEAD OF support for triggers