|Subject||Re: [Firebird-Architect] Generator security - from Database trigger thread|
> It's a subject of extension. The standard allows user-definedI hate to say it, but this relates to the next obvious can of
> increments defined at the DDL level. We just need to extend
> the system tables to store the extra properties. After that
> everybody who has USAGE privilege (also to be implemented)
> can call NEXT VALUE and only an owner of the generator can
> alter the current value.
> The major question is whether we should still allow full-
> featured GEN_ID() calls (as a legacy insecure stuff) or treat
> any non-1 increment as ALTER and hence require the developer
> to adjust his code to the new rules.
worms; Security over functions (internal and UDF).
If security over functions is implemented then you dont need
to totally deprecate gen_id as insecure. It can be left in and
upgrades to existing databases simply to a grant to public to
restore the old behaviour.