Thread

1. drop-in-ability (was: RE: Re: [PATCHES] Select parser a t runtime )

   Alex Avriette <a_avriette@acs.org> — 2001-08-13T14:54:34Z

   I sent the list a message a little while ago about what I do with postgres.
   I thought, after all this discussion, that it might be important to send a
   further message to the list indicating why I chose not to use Oracle.
   
   I'm going to go out on a limb and say that I have one of the largest
   postgres databases in the world. At our site, we have quite a few oracle
   instances and something like 27 schemas (and, I'm afraid to report, a few
   Access as well). Our PG database dwarfs all the other databases combined.
   
   I chose postgres not because of any cost issue at all. The project that I am
   working on here is accustomed to spending $25,000 in a given week for new
   hardware, we bring on consultants as we need them et cetera. To me, what
   made postgres attractive was how simple it was to install and configure.
   Furthermore, I have had discussions with our oracle DBA's. When I mentioned
   I thought our number of rows could reach into the tens of millions, and the
   eventual storage estimate is something on the order of several terabytes, he
   told me I would need to hire on 2-3 fulltime DBA's if I wanted to use
   Oracle.
   
   My feeling on whether postgres is a "drop-in" replacement for Oracle is
   similarly simple. Any sufficiently competent programmer can make
   database-independant code. Up to this point, I have been working hard to
   make sure that, should higher management decide to use Oracle, I can use
   pg_dump and actually just move on over to Oracle. I would have chosen a
   similar approach if I had started with Oracle. Perhaps it is my background
   as a Perl programmer (it is the DataBase Independant driver, afterall), or
   perhaps it is my fear of change. But if you guys are concerned that one
   database is not a drop-in replacement for another, you are paying your
   programmers too much. I think perhaps it is the "Oracle Mentality" (or dare
   I say, Microsoft Mentality) to not worry about portability and compatibility
   that breeds this kind of programming and production. It is very much
   against, however, the opensource mentality.
   
   Dont beat yourself up, guys, over making postgres a drop-in replacement for
   Oracle. The people that would benefit from actually "dropping in" postgres
   into an Oracle install will have already eased the burden on themselves by
   being responsible in their database construction and programming. I haven't
   even been able to convince our Oracle guys that Postgres is actually a "real
   database" (its free?!! how can it be free?!). They would never, (ever!)
   consider dropping in postgres. If you're intent on taking "customers" from
   Oracle, catch them where youll be able to convert them -- before Oracle is
   even installed.
   
   alex
   
   

2. Re: drop-in-ability (was: RE: Re: [PATCHES] Select parser a t runtime )

   Ian Lance Taylor <ian@airs.com> — 2001-08-13T17:26:41Z

   Alex Avriette <a_avriette@acs.org> writes:
   
   > Dont beat yourself up, guys, over making postgres a drop-in replacement for
   > Oracle. The people that would benefit from actually "dropping in" postgres
   > into an Oracle install will have already eased the burden on themselves by
   > being responsible in their database construction and programming. I haven't
   > even been able to convince our Oracle guys that Postgres is actually a "real
   > database" (its free?!! how can it be free?!). They would never, (ever!)
   > consider dropping in postgres. If you're intent on taking "customers" from
   > Oracle, catch them where youll be able to convert them -- before Oracle is
   > even installed.
   
   In principle, I agree with you.  However, my company (Zembu) has a
   business need for better Oracle compatibility, based on real customer
   need.
   
   Zembu doesn't don't have a need to make Postgres a drop-in replacement
   for Oracle; that is a nearly impossible task in any case, because
   Oracle DBAs don't know how to manage Postgres, and most don't want to
   learn.  Zembu does have a need to permit applications to speak to both
   Oracle and Postgres.
   
   Just to be clear, I am not on the Postgres development team.  I'm
   talking about work which is important for Zembu, and which I believe
   can be quite helpful to Postgres in general.  I'm trying to structure
   the work so that even if accepted it would not take too many cycles
   away from core Postgres development.
   
   Ian