Обсуждение: AW: AW: [HACKERS] Re: PostgreSQL reference manual

> >
>> David Gould writes:
>> > Consider also not updateing the grammar. The strength of PostgreSQL is that
>> > functions can be added to work inside the server. These functions can often
>> > do whatever is being proposed as new syntax.
>>
>> So you want me to not check the syntax while parsing the embedded SQL code?
>
>What I think we was suggesting is that we add non-ANSI functionality as
>function calls rather than grammer changes with keywords.  The only
>disadvantage is that it is a little more cumbersom, and less intuitive
>for users.

but it ** is ** ANSI functionality, look under "role"  (with an O)

Andreas

Andreas:
> >> David Gould writes:
> >> > Consider also not updateing the grammar. The strength of PostgreSQL is that
> >> > functions can be added to work inside the server. These functions can often
> >> > do whatever is being proposed as new syntax.
> >>
> >> So you want me to not check the syntax while parsing the embedded SQL code?
> >
> >What I think we was suggesting is that we add non-ANSI functionality as
> >function calls rather than grammer changes with keywords.  The only
> >disadvantage is that it is a little more cumbersom, and less intuitive
> >for users.
>
> 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.

-dg

David Gould            dg@illustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
 - Linux. Not because it is free. Because it is better.

> > 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

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