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
> (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
Well, far be it for me to want or suggest that we be exactly like
1> select 0x0F
(1 row affected)
1> select x'0F'
Msg 207, Level 16, State 2:
Invalid column name 'x'.
In response to
pgsql-hackers by date
|Next:||From: Maurice Gittens||Date: 1998-03-27 22:05:16|
|Subject: Re: [HACKERS] Going on vacation|
|Previous:||From: Bruce Momjian||Date: 1998-03-27 21:16:03|
|Subject: Subquery limits|