Subject | Re: [Firebird-Architect] IN LIST |
---|---|
Author | Jim Starkey |
Post date | 2006-12-03T17:08:48Z |
Roman Rokytskyy wrote:
re-use of cached statements, which is a huge gain in high volume
systems. The Vulcan DSQL implementation was designed to support a
compiled statement cache, though the cache itself has not yet been
implemented. Anything that encourages use of generated statements works
against this. Beefing up the IN LIST syntax to encourage generated
rather than parameterized statements will work against this.
Personally, I haven't seen substantial case for ranges within an IN
LIST. Is it intended only as syntactic sugar, does it allow a user to
do something he or she otherwise couldn't do, or is a convenience construct?
Once again, this is an example of solution presented without a problem.
If we knew what problem this statement was intended to solve, it would
be a great deal easier to evaluate it.
Could we go back to the beginning with a clear statement of a system
requirement?
>> Hence, a way to pass indeterminate number of intervals is very great:Let me take that a bit further. Parameterizing a statement allows
>> select * from t where id in list '5-10,20-30,50'
>>
>
> How is it supposed to work with the parameters? If it doesn't, than it
> requires constructing the statement on the fly which does not really differs
> from a combination of BETWEEN and OR predicates.
>
>
re-use of cached statements, which is a huge gain in high volume
systems. The Vulcan DSQL implementation was designed to support a
compiled statement cache, though the cache itself has not yet been
implemented. Anything that encourages use of generated statements works
against this. Beefing up the IN LIST syntax to encourage generated
rather than parameterized statements will work against this.
Personally, I haven't seen substantial case for ranges within an IN
LIST. Is it intended only as syntactic sugar, does it allow a user to
do something he or she otherwise couldn't do, or is a convenience construct?
Once again, this is an example of solution presented without a problem.
If we knew what problem this statement was intended to solve, it would
be a great deal easier to evaluate it.
Could we go back to the beginning with a clear statement of a system
requirement?