Warning: If you change a domain's definition, existing PSQL code using that domain may become invalid. If this happens, the system table field
RDB$VALID_BLR will be set to
0 for any procedure or trigger whose code is no longer valid. If you have changed a domain, the following query will find the code modules that depend on it and report the state of
select * from ( select 'Procedure', rdb$procedure_name, rdb$valid_blr from rdb$procedures union select 'Trigger', rdb$trigger_name, rdb$valid_blr from rdb$triggers ) (type, name, valid) where exists (select * from rdb$dependencies where rdb$dependent_name = name and rdb$depended_on_name = 'MYDOMAIN') /* Replace MYDOMAIN with the actual domain name. Use all-caps if the domain was created case-insensitively. Otherwise, use the exact capitalisation. */
Unfortunately, not all PSQL invalidations will be reflected in the
RDB$VALID_BLR field. It is therefore advisable to look at all the procedures and triggers reported by the above query, even those having a
1 in the "
Please notice that for PSQL modules inherited from earlier Firebird versions (including a number of system triggers, even if the database was created under Firebird 2.1 or higher),
NULL. This does not indicate that their BLR is invalid.
SHOW PROCEDURES and
SHOW TRIGGERS flag modules whose
RDB$VALID_BLR field is zero with an asterisk.
SHOW PROCEDURE PROCNAME and
SHOW TRIGGER TRIGNAME, which display individual PSQL modules, do not signal invalid BLR.
Added in: IB
Renaming of a domain is possible with the
TO clause. This feature was introduced in InterBase 6, but left out of the Language Reference.
alter domain posint to plusint
TOclause can be combined with other clauses and need not come first in that case.
Changed in: IB
Any context variable that is assignment-compatible to the domain's data type can be used as a default. This was already the case in InterBase 6, but the Language Reference only mentioned
alter domain DDate set default current_date