Thomas G. Lockhart wrote:
>
> > > 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'
Well, far be it for me to want or suggest that we be exactly like
Sybase, but:
1> select 0x0F
2> go
----
0x0f
(1 row affected)
1> select x'0F'
2> go
Msg 207, Level 16, State 2:
Line 1:
Invalid column name 'x'.
1>
Ocie