Dear Ann, Jim, all,

Thank you for your answers. I have more questions ;-)

But first commenting on one of Ann's comment:

> The SQL standard has a much less happy history than
> the C++ standard. The development of the standard
> has been dominated by large vendors who appear to care
> more about protecting their implementation than developing
> a coherent standard.

Of course the C++ std has its dark spots too, but in an
amazing example of professionalism, it looks like a
collective learning process: after the experiences
show a problem, most expert agree where the standard went
wrong.

But if the 'only' problem with the SQL standard is the
influence of the big vendors, why don't they get their own
implementation more in line with the standard (or the other
way around)?

OK, that was a bit OFF TOPIC, now back to Firebird.

I really should wait until I've learned more, before starting
to discuss concrete points in standard conformance, but I can't
help to single out some 'easy' points.

If I neither mis-interpret the standard nor Firebird's behaviour,
there is a disagreement here:

1. Naming constraints in DOMAIN definition
Firebird doesn't allow the standard syntax
CREATE DOMAIN d AS INTEGER
CONSTRAINT d_must_be_positive CHECK (value > 0);

2. Giving multiple rows in VALUE
Firebird doesn't allow the standard syntax
INSERT INTO t COLUMN (c1,c2) VALUES (1,2),(3,4),(5,6);

Neither of these points is catastrophic, but I guess (perhaps
rather wrong) that they can easily being corrected.

Best Regards,
Peter Jacobi
Hamburg, Germany