Hi Helen e.a., Am 30.11.2011 19:32, schrieb Helen Borrie: >>> On 11/30/11 02:42, Frank Ingermann wrote: >>>> DROP SOURCE OF [<procedure name>|<trigger name>|*] >>>> or >>>> CHANGE OWNER OF [<db object>|*] TO<new_owner> <snip> >> I don't think bloat the language with non-standard syntax for >> non-mainstream tasks is a good thing.
@Adriano: i don't like that, either - that's why i asked if there is any "standard" syntax to do it (i'm not that familiar with the "standard".) If there is one, we should stick to it, certainly! <snip> > ALTER<procedure name>|<trigger name> > SET SOURCE NULL > > ALTER<object name> > SET OWNER =<user-name> I don't really mind the syntax, BUT: nowadays one would do UPDATE RDB$... SET RDB$..SOURCE ... NULL (without a WHERE!) to wipe out ALL the SOURCEs in one go. The "*" in my example was just to indicate that it would be desirable to keep that ability, that is: not having to issue a statement for every single SP/Trg. _individually_ - as DBs evolve, that would be quite troublesome to maintain. (Boss: "damn, why is the source of that new SP with all our clever business logic plain readable in our deployment db?" - emp.: "sorry, i forgot to add a line for that SP into our "obfuscating" script" -> boss mails personnel office... :-( ?? Yes, we all know that wiping the sources does not prevent that "clever business logic" from being stolen - but it does require some "criminal energy" to reconstruct it from BLR, while leaving it in plain readable SQL can be regarded as carelessness/thougtlessness/improvidence/whatever. (that can make the difference between a) accepted "pseudo-security" and b) losing your job if someone finds out.) > Incidentally, if some kind of "change owner" feature is added, it should be > severely restricted to SYSDBA only, IMO, since no check is done to determine whether any user exists in the security DB -- although perhaps that improvement might be made possible in v.3 with the advent of the database-level security db's? Good point - as i wrote earlier, security will have to be considered really carefully. Still i think it's a no-go to just take the ability _away_ to clear out those sources. It IS common practise. cheers, Frank ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
