> > but it ** is ** ANSI functionality, look under "role" (with an O)
> Ok, but are we using the ANSI syntax? If so, then I withdraw my
> objection. But, if we are adding ANSI functionality with UNIQUE
> syntax, then why bother hacking the parser since the functionality can
> be added with functions.
We don't have a goal of implementing unique syntax *just because*,
although it may look that way from time to time. If the syntax can be
made compliant without damaging the functionality, we will make it SQL92
compatible (or compatible with whatever standard makes sense).
btw, this brings up a question:
The MySQL bunch have included some syntax in their "crash-me" test which
is _not_ SQL92 compliant, including hex constants specified as
0x0F
(for decimal 15, assuming I've done the conversion right :). They claim
that this is required by the ODBC standard, whatever that is. What is
the relationship between the two? Isn't ODBC a client interface, not
necessarily dealing with SQL directly but rather with common SQLish
functionality? In cases where SQL92 and ODBC conflict, how do systems
resolve the differences? For this case, SQL92 clearly defines the syntax
as
x'0F'
In this particular case it will be easy to implement this ODBC syntax in
the scanner, but I don't want to jerk it around too much if it a bogus
issue :(
- Tom