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