Thread: RE: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
>> >IMHO the ANSI standard (as anything designed by a committee) is not >> always >> the >> >best >> >way to do things. Hmmm, quite frequently, yes. < clip > >> My understanding from reading Date is that one reason for not adopting >> the common vendor hacks for outer joins is that outer joins aren't >> associative and the result of complicated expressions in some cases >> will depend on the order in which the RDBMS' optimizer chooses to >> execute them. Yes, that was what I thought as well. I'm not sure what the ANSI standard specifies, but if it's the style used below (which is what Access uses), then it's not overly complicated, but can be a little difficult to read sometimes. >> Putting on my compiler-writer hat, I can see where having joins >> explicitly declared in the "from" clauses rather than derived from >> an analysis of the "from" and "where" clauses might well simplify >> the development of a new SQL 92 RDBMS if one were to start from >> scratch. It's cleaner, IMO. This doesn't apply to Postgres, >> since the outer joins are being shoe-horned into existing data >> structures. Does that make any difference? >> Of course, I speak as someone without >> a lot of experience writing Oracle or Informix SQL. If you're used >> to Oracle, then it's not surprising you find its means of specifying >> an outer join the most natural and easiest to understand... Yes, you're probably right. Although, I learnt SQL using Access and SQL Server, doing the 'A INNER JOIN B ON A.x = B.x' syntax, and I still prefer Oracle's way of doing it. From the developers point of view, it's pretty easy to read (mainly because it doesn't clutter your FROM clause). Perhaps the best would be to implement ANSI outer joins, and then use the rewriter to allow for the Oracle syntax, or something similar, just to add readability to the SQL. MikeA
> the best would be to implement ANSI outer joins, and then use the
> rewriter to allow for the Oracle syntax, or something similar, just to
> add readability to the SQL.
When I tried adding the syntax to gram.y a while ago it gave
shift/reduce errors on the "(+)" fields. I would guess that we would
need to have this become a token in the lexer :((
I'll have the code in gram.y (commented out) when I commit my next
changes for this; someone can play with it if they want.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On Fri, 7 Jan 2000, Thomas Lockhart wrote:
> > the best would be to implement ANSI outer joins, and then use the
> > rewriter to allow for the Oracle syntax, or something similar, just to
> > add readability to the SQL.
>
> When I tried adding the syntax to gram.y a while ago it gave
> shift/reduce errors on the "(+)" fields. I would guess that we would
> need to have this become a token in the lexer :((
>
I'd actually expect a potential reduce/reduce conflict between:
a_expr:func_name '(' ... ')'and a_expr '(' '+' ')'
since func_name is a ColID as is a_expr potentially, so the system must
work out whether the ColID reduces to an a_expr when it sees then '('
which it can't do (it needs another token to work that out).
So yes, you probably need a new lexer token.
> I'll have the code in gram.y (commented out) when I commit my next
> changes for this; someone can play with it if they want.
>
> - Thomas
>
> --
> Thomas Lockhart lockhart@alumni.caltech.edu
> South Pasadena, California
>
.............................Rod
+-----------------------------------------------------------------------------+
| Rod Chamberlin | rod@querix.com Tel +44 1703 232345 |
| Software Engineer | Mob +44 7803 295406 |
| QueriX | Fax +44 1703 399685 |
+-----------------------------------------------------------------------------+
| The views expressed in this document do not necessarily represent those of |
| the management of QueriX (UK) Ltd. |
+-----------------------------------------------------------------------------+