Обсуждение: Ticket 256: add INSTEAD OF support for triggers
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. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Sat, Oct 23, 2010 at 3:00 PM, Guillaume Lelarge
<guillaume@lelarge.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
Le 23/10/2010 14:03, Dave Page a écrit :
> On Sat, Oct 23, 2010 at 3:00 PM, Guillaume Lelarge
> <guillaume@lelarge.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
[Ashesh, if you haven't aready, I suggest reviewing this thread. It may shed some light on that Rule weirdness on Solaris] On Sat, Oct 23, 2010 at 11:03 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: >> pgView derives from pgSchemaObject > > Actually, pgView derives from pgRuleObject, which is already weird by > itself but makes the whole thing even more weird. Oh, I misread that. pgView*Factory* derives from pgSchemaObj*Factory*. Which seems bizarre. >> 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. I think the point is, that pgRule can't be a descendent of a table or a view (in the inheritance hierarchy), because it is a descendent of both (logically). >> 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++. I don't think it needs "more C++ knowledge", just some patience to untangle things. Do you know of any tools that can automatically visually display the object model and members? I'm sure there used to be something in Visual Studio, but I can't find it atm. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Le 24/10/2010 00:18, Dave Page a écrit : > [Ashesh, if you haven't aready, I suggest reviewing this thread. It > may shed some light on that Rule weirdness on Solaris] > > On Sat, Oct 23, 2010 at 11:03 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >>> pgView derives from pgSchemaObject >> >> Actually, pgView derives from pgRuleObject, which is already weird by >> itself but makes the whole thing even more weird. > > Oh, I misread that. pgView*Factory* derives from pgSchemaObj*Factory*. > Which seems bizarre. > >>> 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. > > I think the point is, that pgRule can't be a descendent of a table or > a view (in the inheritance hierarchy), because it is a descendent of > both (logically). > >>> 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++. > > I don't think it needs "more C++ knowledge", just some patience to > untangle things. Do you know of any tools that can automatically > visually display the object model and members? I'm sure there used to > be something in Visual Studio, but I can't find it atm. > Some patience, yeah, I did use that :) New patch attached. Works good for me. -- Guillaume http://www.postgresql.fr http://dalibo.com
Вложения
On Thu, Nov 4, 2010 at 11:19 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Some patience, yeah, I did use that :) > > New patch attached. Works good for me. Eyeball review looks OK. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Le 07/11/2010 06:40, Dave Page a écrit : > On Thu, Nov 4, 2010 at 11:19 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Some patience, yeah, I did use that :) >> >> New patch attached. Works good for me. > > Eyeball review looks OK. > Thanks, commited. -- Guillaume http://www.postgresql.fr http://dalibo.com