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

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