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