[Spacewalk-devel] Re: PGPORT: Orafce

Bruce Momjian bruce at momjian.us
Fri Jan 30 17:25:59 EST 2009


Devan Goodwin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 30 Jan 2009 15:26:36 +0100
> Jan Pazdziora <jpazdziora at redhat.com> wrote:
> 
> > On Fri, Jan 30, 2009 at 09:17:39AM -0500, Jeff Ortel wrote:
> > >
> > > Whether this is done via 1) compatibility layer or 2) migrating
> > > the queries to ANSI SQL or both is another question.  The advantage
> > > of doing it in the compatibility layer is (maybe) lower risk when
> > > running on Oracle.  But, since we know there are many queries that
> > > must be rewritten (for example: queries with the oracle (+) syntax
> > > for outer joins) anyway, why not just do the right thing now and
> > > get it over with while we're committed to spending the $$ and time
> > > to do this?  If satellite is going to become a multi-database
> > > application, shouldn't the application code be as database agnostic
> > > as possible?
> > 
> > Agreed with the intention. But why is this part of the PostgreSQL
> > effort. Shouldn't this be completely independent goal, with its own
> > requirements and plan and test plan?
> 
> I don't see why it should be separated in the first place but if it
> were, it should probably be done before the PostgreSQL effort
> (otherwise there'd be some wasted effort involved) implying that we (a)
> need to put that on hold and (b) find people to do it. We've already got
> people with a strong background in both databases and are already
> prepping for a big test/QA impact, I say hit it while we're in there.

In addition, there is more risk of bugs in using a compatibility layer
than in rewriting the queries to be ANSI-compliant.  We have already
tripped over a number of Orafce bugs, while odds are Oracle and Postgres
implement ANSI just fine.

-- 
  Bruce Momjian  <bruce at momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +




More information about the Spacewalk-devel mailing list