Re: Ticket 256: add INSTEAD OF support for triggers

[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