Re: AW: AW: [HACKERS] Re: PostgreSQL reference manual

ocie@paracel.com

From: ocie@paracel.com
To: lockhart@alumni.caltech.edu (Thomas G. Lockhart)
Cc: dg@illustra.com, andreas.zeugswetter@telecom.at, maillist@candle.pha.pa.us, pgsql-hackers@hub.org
Date: 1998-03-27T21:23:55Z
Lists: pgsql-hackers
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