Обсуждение: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL

Поиск
Список
Период
Сортировка

Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL

От
Don Baccus
Дата:
At 12:49 PM 1/6/00 +0000, Rod Chamberlin wrote:

>    4/    Informix outer join syntax
>        o    informix uses outer joins of the form
>            SELECT * FROM a, outer b where a.nr = b.nr
>            This will require some post-processing to determine
>            the actual join conditions.

Rather than go blow-by-blow, why should Postgres adopt (say) Informix
syntax vs. Sybase or Oracle?

If Postgres were to adopt a non-standard syntax for a feature like outer
joins, wouldn't it make more sense to pick the syntax used by the market
leader (Oracle), simply because it would make porting easier for a much
larger group of database users?

Of course, my REAL feeling is that supporting SQL 92 outer join syntax - which
is the approach being taken by the developers - is the right answer.

And, of course, that Oracle, Informix and the rest ought to get off their
collective asses and support SQL 92.  After all, they undoubtably contributed
to the development of those standards - I can't believe they didn't fund
representatives to the committees.

But if one were to want to mimic a commercial DB, one would presumably
mimic the market leader...



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


Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL

От
Rod Chamberlin
Дата:
On Thu, 6 Jan 2000, Don Baccus wrote:

> At 12:49 PM 1/6/00 +0000, Rod Chamberlin wrote:
> 
> >    4/    Informix outer join syntax
> >        o    informix uses outer joins of the form
> >            SELECT * FROM a, outer b where a.nr = b.nr
> >            This will require some post-processing to determine
> >            the actual join conditions.
> 
> Rather than go blow-by-blow, why should Postgres adopt (say) Informix
> syntax vs. Sybase or Oracle?
> 
> If Postgres were to adopt a non-standard syntax for a feature like outer
> joins, wouldn't it make more sense to pick the syntax used by the market
> leader (Oracle), simply because it would make porting easier for a much
> larger group of database users?
> 
> Of course, my REAL feeling is that supporting SQL 92 outer join syntax - which
> is the approach being taken by the developers - is the right answer.
> 
> And, of course, that Oracle, Informix and the rest ought to get off their
> collective asses and support SQL 92.  After all, they undoubtably contributed
> to the development of those standards - I can't believe they didn't fund
> representatives to the committees.
> 
> But if one were to want to mimic a commercial DB, one would presumably
> mimic the market leader...

Actually what I'm proposing is more to support mutiple database syntaxes
wherever possible.  The INFORMIX style of outer join (and for that matter
the oracle style), are not gramatically exclusive.  There is no reason why
you should not allow *all* sane outer join syntaxes, apart from the added
complexity in the parser.  

The same is true largely for the other changes I suggested.  They are for
portability with other systems to attempt to minimise the amount of work
necessary to migrate a given application.

Why is this interesting for Informix?  Two reasons I can list
offhand:

1/    Informix is currently deserting it's customer base of small
business users, instead trying to concetrate on larger organisations.
There are therefore vasts numbers of users crying out for something to
fill that gap.  This I will admit provides a commercial basis for any such
attempt, since we have already got some of the other tools which
informix users will be interested in.

2/    The datatypes already tie in much more closely in informix than
they do in oracle (I can't speak for any of the other major
databases, I haven't actually looked at the type comparisons). Actually
trying creating a useable sensible level of compatability with oracle
would take considerably more work than doing the same for informix.


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



Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL

От
Brian E Gallew
Дата:
Then <dhogaza@pacifier.com> spoke up and said:
> But if one were to want to mimic a commercial DB, one would presumably
> mimic the market leader...

Market leader or not, Oracle causes us sufficient pain here that I
would never consider it important.  But then again, I'm bitter.

-- 
=====================================================================
| JAVA must have been developed in the wilds of West Virginia.      |
| After all, why else would it support only single inheritance??    |
=====================================================================
| Finger geek@cmu.edu for my public key.                            |
=====================================================================

Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL

От
Don Baccus
Дата:
At 03:09 PM 1/6/00 +0000, Rod Chamberlin wrote:
I wrote:
>> Rather than go blow-by-blow,

(I meant blow-by-blow through Rod's list)...

>Actually what I'm proposing is more to support mutiple database syntaxes
>wherever possible.  The INFORMIX style of outer join (and for that matter
>the oracle style), are not gramatically exclusive.  There is no reason why
>you should not allow *all* sane outer join syntaxes, apart from the added
>complexity in the parser.  

Well, there are reasons, actually.  Documentation as well as the parser
becomes more complex, and ... well ... it's messy and ugly.  

>
>The same is true largely for the other changes I suggested.  They are for
>portability with other systems to attempt to minimise the amount of work
>necessary to migrate a given application.

In many cases you could write a pre-processor to bulk-translate stuff
if you wanted.  Indeed, friends and I porting the Ars Digita Community
system have done some of that ourselves (moving it from Oracle).

>Why is this interesting for Informix?  Two reasons I can list
>offhand:

>1/    Informix is currently deserting it's customer base of small
>business users, instead trying to concetrate on larger organisations.
>There are therefore vasts numbers of users crying out for something to
>fill that gap.  This I will admit provides a commercial basis for any such
>attempt, since we have already got some of the other tools which
>informix users will be interested in.

So write a portability tool to help them move their stuff.

Just MHO, of course.



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