Subject | Re: [Firebird-Architect] Re: Standard Conformance |
---|---|
Author | Ann W. Harrison |
Post date | 2003-06-17T17:12:29Z |
Peter,
all different, by any compromise each implementation will
be wrong in some aspects.
are a lot of places, small and larger, that we don't completely
support. UNION DISTINCT is one example - we don't (I think)
handle the keyword DISTINCT which is really just noise - the
default union eliminates duplicates. Easy enough to do, but
of value to whom?
Regards,
Ann
www.ibphoenix.com
We have answers.
>But if the 'only' problem with the SQL standard is theI guess if you start with three reference implementations,
>influence of the big vendors, why don't they get their own
>implementation more in line with the standard (or the other
>way around)?
all different, by any compromise each implementation will
be wrong in some aspects.
>If I neither mis-interpret the standard nor Firebird's behaviour,Looking over the matrix you pointed out, I notice that there
>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);
are a lot of places, small and larger, that we don't completely
support. UNION DISTINCT is one example - we don't (I think)
handle the keyword DISTINCT which is really just noise - the
default union eliminates duplicates. Easy enough to do, but
of value to whom?
Regards,
Ann
www.ibphoenix.com
We have answers.