Subject | Re: [Firebird-Architect] Database triggers |
---|---|
Author | Jim Starkey |
Post date | 2006-09-20T20:49:13Z |
Jonathan Neve wrote:
wakes up knowing about them. The access paths are otherwise identical.
So unless somebody has gone out of their way to outlaw triggers on
system tables, then should work.
Triggers on system tables are probably straightforward to implement in
gbak, though I will admit that I haven't looked deeply in gbak for about
15 years. But it should be a piece of (useful!) cake.
--
Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376
> Hi Jim,There is nothing magic about system tables other than that the system
>
> Thanks for your reply!
>
> Jim Starkey wrote:
>
>> It was designed to do just that. The problem is that gbak never got
>> fixed to backup and restore extensions to system tables. And, I'm
>> afraid, gbak never got fixed because it's significantly non-trivial.
>>
>> Now, all that said, when I had to do the whole thing all over again, I
>> made system tables not only non-extensible by users, but completely
>> non-writable by users.
>>
>> Even though it may be possible, I strongly urge you not to extend the
>> system tables. Set up parallel but separate tables and save yourself a
>> great deal of grief.
>>
>>
>
> Very interesting.
>
> In my case, I do indeed use my own parallel tables (since there isn't
> any other option), and I can understand that it probably wouldn't make
> sense to introduce a tricky feature into the engine considering that it
> would only seldom get used. Besides, at least that way the exact
> structure of the system tables can be counted on.
>
> In that case, I would be interested to see at least triggers working on
> system tables, if, again, that doesn't cause too big of an upheaval for
> gbak. That would allow those of us who would have had a use for custom
> extentions to the system table to have something almost as good: the
> ability to automatically keep in sync a parallel table with the real
> underlying one by using triggers. Triggers on the system tables would
> also, of course, make logging meta-data changes very easy (whereas now
> it's hardly possible).
>
wakes up knowing about them. The access paths are otherwise identical.
So unless somebody has gone out of their way to outlaw triggers on
system tables, then should work.
Triggers on system tables are probably straightforward to implement in
gbak, though I will admit that I haven't looked deeply in gbak for about
15 years. But it should be a piece of (useful!) cake.
--
Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376