Re: AW: AW: [HACKERS] Re: PostgreSQL reference manual
От | ocie@paracel.com |
---|---|
Тема | Re: AW: AW: [HACKERS] Re: PostgreSQL reference manual |
Дата | |
Msg-id | 9803272123.AA17759@dolomite.paracel.com обсуждение исходный текст |
Ответ на | Re: AW: AW: [HACKERS] Re: PostgreSQL reference manual ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | 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
В списке pgsql-hackers по дате отправления: