Subject | RE: [Firebird-Architect] Feature Request: Domains in SP & |
---|---|
Author | Dmitry Yemanov |
Post date | 2004-10-12T16:44:40Z |
"Ann W. Harrison" <aharrison@...> wrote:
feature in another forum, I suggested something like typeof(<domain>) to be
even more clear. But this is just a syntactic sugar.
We have two issues to take into account:
1) FB 2.0 introduces default values for procedure parameters, and they're
obviously stored in system-generated domains. In this case my typeof()
suggestion doesn't match the semantics, while BASED ON still may be used.
But, to provide the same level of functionality, BASED ON should use domain
defaults. We cannot use BASED ON <MY_DOMAIN> DEFAULT 'QWERTY', because
there's no place to store 'QWERTY' except domain MY_DOMAIN which may already
contain another default value.
2) When we later will be ready to reliably support e.g. check constraints in
procedure parameters, the syntax should be ready for that. Again, BASED ON
looks more appropriate in this case. But any such extention may break
existing databases, as they may rely on a fact that BASED ON feature ignores
check contraints.
Any ideas?
Dmitry
>only
> >Would you be happy with BASED ON functionality? This way, it would take
> >the data type and everybody's clear it's not the whole domain.Generally, I agree with the idea too. Although when I was discussing this
>
> I like that idea - and tracking datatype changes is MUCH easier than
> deciding how (and when) to apply constraints, etc.
feature in another forum, I suggested something like typeof(<domain>) to be
even more clear. But this is just a syntactic sugar.
We have two issues to take into account:
1) FB 2.0 introduces default values for procedure parameters, and they're
obviously stored in system-generated domains. In this case my typeof()
suggestion doesn't match the semantics, while BASED ON still may be used.
But, to provide the same level of functionality, BASED ON should use domain
defaults. We cannot use BASED ON <MY_DOMAIN> DEFAULT 'QWERTY', because
there's no place to store 'QWERTY' except domain MY_DOMAIN which may already
contain another default value.
2) When we later will be ready to reliably support e.g. check constraints in
procedure parameters, the syntax should be ready for that. Again, BASED ON
looks more appropriate in this case. But any such extention may break
existing databases, as they may rely on a fact that BASED ON feature ignores
check contraints.
Any ideas?
Dmitry