Re: [HACKERS] Enhancing PGSQL to be compatible with InformixSQL
От | Don Baccus |
---|---|
Тема | Re: [HACKERS] Enhancing PGSQL to be compatible with InformixSQL |
Дата | |
Msg-id | 3.0.1.32.20000106185741.00ed7b6c@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Enhancing PGSQL to be compatible with InformixSQL (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Ответы |
Re: [HACKERS] Enhancing PGSQL to be compatible with InformixSQL
|
Список | pgsql-hackers |
At 07:08 PM 1/6/00 +0000, Thomas Lockhart wrote: >> I've been wanting outer joins, but in my porting efforts have managed >> to work around them without too much difficulty, even though 6.5's >> limitations on subselects (not in target lists) requires that I >> create PL/pgSQL functions in some cases. >> I certainly can't speak for the majority of users, but as one data >> point I'd personally rather see outer joins done right (SQL 92 >> syntax) and wait a bit. > >A bit of a misunderstanding here: we are using SQL92 syntax but will >try to implement the outer join operation using *internal* data >structures similar to what we have now. Yes, I've seen the existing code, in particular regarding inner joins. >Any alternate syntaxes are just a diversion which slow us down on the >road to world domination ;) That's my first feeling, too, as I hope I made clear. If you don't mind my asking, just what are the difficulties? Bruce mentioned the optimizer. I noticed the executor code that does merge joins has conditionalized stuff in it to insert the nulls required by outer join. And the parser has conditionalized stuff to deal with them. So, is it ("just", he says :) the optimizer, or more? - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: