Re: Ticket 256: add INSTEAD OF support for triggers
От | Dave Page |
---|---|
Тема | Re: Ticket 256: add INSTEAD OF support for triggers |
Дата | |
Msg-id | AANLkTimny1PmR-0=gyi48y7BqQM=iNKwsyOnNsBdiuHv@mail.gmail.com обсуждение исходный текст |
Ответ на | Ticket 256: add INSTEAD OF support for triggers (Guillaume Lelarge <guillaume@lelarge.info>) |
Ответы |
Re: Ticket 256: add INSTEAD OF support for triggers
|
Список | pgadmin-hackers |
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
В списке pgadmin-hackers по дате отправления: