Hi.

* New built-in functions for converting UUID CHAR(16) OCTETS strings
to RFC4122-compliant format and vice versa

Generalization suggested:

CREATE DOMAIN GUID AS CHAR(32)
STORE AS CHAR(16) OCTETS
READ AS CHAR_TO_GUID(VALUE)
WRITE AS GUID_TO_CHAR(VALUE);

What does it mean:
The column with domain GUID is visible as CHAR(32) everywhere but
stored and indexed as CHAR(16) internally.

Reason:
The only problem with GUID(32) is storage inefficency (including
string reversing). I think that GUID is not the only case. So why not
allow to explicitly state the storage format.
In this form any read access to the column calls read-transform and
any write access calls write-transform:

CREATE <DOMAIN_NAME> AS <TYPE DEF>
[DEFAULT <EXPR>]
[NOT NULL]
...
[STORE AS <STORAGE TYPE> READ <READ TRANSFORM> WRITE <WRITE TRANSFORM>]

where <READ|WRITE TRANSFORM> are expressions taking one paramenter VALUE.

I see many good uses for predefined (like Hibernate-created) DB
schemas to be implemented in FB more efficently. Like string <->
numeric, date <-> numeric or string, etc.


Maxim.