Comment by ken
7 years ago
That "most" is a pretty loaded word! Last I checked, even CREATE INDEX is not part of any ANSI or ISO SQL specification. (That's why every RDBMS has such different features and syntax for this.) Good luck building a system with just "standard SQL".
> even CREATE INDEX is not part of any ANSI or ISO SQL specification
That's correct, and that's why PostgreSQL has ADD CONSTRAINT.
The constraints describe the actual schema of the data; INDEX is an DBMS-specific implementation* for improving performance (including index types, etc.).
* Those since the standard does not yet cover some thing partial unique constraints, these have to be done as INDEX in PostgreSQL.
SQL has nothing to say about the layer of physical implementation, and that's where INDEX belongs (as does STOGROUP [DB2] and what have you).
That's not a bug, that's a feature. Deriving from the deliberate intent to make physical independence (which was simply nonexistent at the time the model was conceived) a reality.
Why should it be? Indexing is an implementation detail for each RDBMS, so it doesn’t make sense to add it to the language spec.
It does make sense when the goal of the language spec is interoperability, and it's something that everyone has to do, in practice, no matter the platform.
Call it a "hint", if you will, the meaning of which is implementation defined. But standardize the syntax for pete's sake.
Interoperability is achieved if the same query with the same inputs yields the same result. "In the same amount of time" (which is the part that indexes are aimed at) is manifestly not part of that picture, and that's by design.
And "hints" in the language are not exactly going to improve "interoperability" if their meaning is still allowed to be implementation-defined, are they ?
That sounds backwards to me. It's only lack of standardization that forces it to be an "implementation detail". To any application that needs to be able to query data in reasonable time, it's fundamental and necessary functionality.