Subject | Re: [Firebird-Architect] Generator security - from Database trigger thread |
---|---|
Author | Jim Starkey |
Post date | 2006-09-20T04:23:06Z |
Dmitry Yemanov wrote:
standard requires it. Perhaps after you understand it, you will
understand why there are alternatives, some of which may be better.
Good design *always* starts with a clear understanding of requirements.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
> Geoff Worboys wrote:I think you need to understand why this is important other than that the
>
>> That was the point of my comment "except that we dont seem to
>> store the increment as part of the generator definition".
>> If the increment was part of the generator definition then
>> the "standard" would be defined. That aspect is not feasible
>> with the current implementation.
>>
>
> It's a subject of extension. The standard allows user-defined 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.
>
>
standard requires it. Perhaps after you understand it, you will
understand why there are alternatives, some of which may be better.
Good design *always* starts with a clear understanding of requirements.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376