Dmitry Yemanov wrote:

> Adriano,
>
>
>> It was implemented using the "BASED ON <name>" approach, so check
>> constraints are not applied. NOT NULL from domain is used.
>>
>
> First, why some constraints (NOT NULL) are applied whilest others (check
> ones) are not? This doesn't look consistent to me.
>

While NOT NULL is a constraint, I see it as a complement of the data type.
But seems to be only me. :-)

> Then, it we inherit *all* constraints, I think we should use a plain domain
> name without the BASED ON clause, so the usage syntax and semantics would be
> the same as for tables. If we apply *no* constraints, then BASED ON sounds
> fine to me. Although if we talk about datatypes only, I'd prefer something
> like TYPE OF <name> instead. Moreover, both alternatives could co-exist:
>

If we not apply NOT NULL I also prefer TYPE OF.

> CREATE DOMAIN BOOLEAN AS SMALLINT CHECK (VALUE IN (0, 1));
> DECLARE MY_VAR BOOLEAN; -- constraints are applied
> DECLARE MY_VAR TYPE OF BOOLEAN; -- constraints are ignored
>
>
>> It should be usable in CAST too. But BASED ON syntax is not good
>> for CAST. Currently it works in CAST without BASED ON prefix.
>>
>
> 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.
BTW, TYPE OF looks good with CAST.

>
>> NOT NULL parameters/variables are initialized to data type default
>> value, i.e., 0 for INTEGER, etc.
>>
>
> And 17.11.1858 for dates? :-)
>

Should I renounce of NOT NULL for now? ;-)

We may require assignment in the declaration of NOT NULL variables

But default assignment of NOT NULL output parameters seems not logical.
If we support constraints we need to do something about it.

>
>> Variables are internally created with new "blr_based_on <name>",
>> hence domain changes are automatically propagated.
>>
>
> Okay, but it can easily make the PSQL code broken if the type change is done
> in a not compatible way (e.g. a CHAR->INT change). Do you want to prohibit
> that based on dependencies? Or do you plan to control BLR invalidation and
> throw an appropriate error?
>

We can easy do one of the two things:
1) Use the dependencies and don't allow such type of incompatible
change. That will prevent some changes that make procedures continuing
work correctly.
2) Allow the change and let procedure fail at runtime.

>
>> Explicit NOT NULL data types are prefixed with new blr_not_nullable.
>> Examples:
>> INTEGER NOT NULL -> blr_not_nullable, blr_long, ...
>> BASED ON CUSTOM_TYPE NOT NULL -> blr_not_nullable, blr_based_on, ...
>>
>
> And I foresee INTEGER CHECK(...) in the future :-)
>
> Also, what's about non-SQL procedures? Will the constraints work for them
> too?
>

What you mean by non-SQL procedures?
Currently, there is no difference with NOT NULL for SQL/BLR procedures.

> Thinking about that, I'm already not that sure that constraint definitions
> should be allowed for parameters and variables. For a table, it's just an
> alternative to an user trigger, so it saves you one object definition. In
> PSQL, however, you need to write a PSQL body anyway, so IMO it's not a big
> deal to add an IF statement in the beginning.
>

I agree for variables and output parameters, but not for input parameters.

>
>> Things not implemented yet:
>>
>> Explicit NOT NULL of parameters should be stored at some other place.
>> Logical candidate is RDB$PROCEDURE_PARAMETERS.
>>
>> Default parameters of SPs in V2 are stored at the implicit created
>> domain, so it's the same situation as above.
>>
>
> And then also RDB$VALIDATION_SOURCE / RDB$VALIDATION_BLR? Is such a
> complexity really worth the value?
>

We may better defer constraints.
People want primary domain data type and we can have both working in the
future with different syntax.

About default parameter value, I mean we already can use defaults and
they go to RDB$FIELDS.
If we allow procedure defaults for domain parameters, we need to store
it and can't change the already existing RDB$FIELD record.


Adriano