Hi,

>>> Per SQL-2003, CAST(<value> AS <domain name>) is perfectly legal, so
>>> I agree here.
>>>
>> Yes, but if we have syntax that apply and that not apply constraints we
>> need two syntax for cast too.

> Why? CAST knows nothing about constraints and it shouldn't. Casting some
> value to domain D should not mean that the value will acquire any constraint
> definition from D. It's about datatypes only.

I'm not sure i understand your point, but the result of CAST(<value> AS <domain>) should meet the domain constraints.

This is from the SQL standard:

--------------------------------------------------------------------------------
4.17.4 Domain constraints
A domain constraint is a constraint that is specified for a domain. It is applied to all columns that are based on

that domain, and to all values cast to that domain.

68 Foundation (SQL/Foundation)

IWD 9075-2:200x(E)

4.17 Integrity constraints

A domain constraint is described by a domain constraint descriptor. In addition to the components of every

constraint descriptor, a domain constraint descriptor includes:

- The template <search condition> for the generation of domain constraint usage <search condition>s.

- A possibly empty set of domain constraint usages.

A domain constraint usage descriptor is created implicitly by the evaluation of a <column definition> whose

<data type or domain name> is a <domain name>. If C is such a column and D is the domain identified by the

<domain name>, then every domain constraint DC defined for D implies a domain constraint usage, to the

effect that each value in C satisfies DC.

In addition to the components of every table constraint descriptor, a domain constraint usage descriptor includes:

- The name of the applicable column.

- The applicable <search condition> that evaluates whether each value in C satisfies DC.

A domain constraint is satisfied by SQL-data if and only if, for every table T that has a column named C based

on that domain, the applicable <search condition> recorded in the appropriate domain constraint usage evaluates

to True or Unknown.

A domain constraint is satisfied by the result of a <cast specification> if and only if the specified template

<search condition>, with each occurrence of the <general value specification> VALUE replaced by that result,

evaluates to True or Unknown.
--------------------------------------------------------------------------------

> 1) Any domain change marks all dependent BLRs as invalid. Any parsing or
> execution of such BLR is rejected with an appropriate error. This "invalid"
> flag is cleared as soon as the BLR gets successfully regenerated and parsed.
> The flag is persistent, so it should be stored in the schema. This is the
> most reliable approach, as it should catch all possible errors, but it's
> also quite hard in use (it requires manual processing and perhaps also SQL
> source to be available).

Why SQL-source? To give a good report to user?

Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database developer support:
http://www.databasedevelopmentforum.com

Firebird open source database (based on IB-OE) with many SQL-99 features:
http://www.firebirdsql.org
http://www.firebirdsql.info

Support list for Interbase and Firebird users:
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep:
news://newsgroups.firebirdsql.info