From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Marc Lavergne <mlavergne-pub(at)richlava(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: C vs. C++ contributions |
Date: | 2002-08-27 16:33:24 |
Message-ID: | 200208271633.g7RGXOV28937@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marc, wher did we leave this? Also, 7.3 will have prepared statements
in the backend code, so that should make the porting job easier.
---------------------------------------------------------------------------
Marc Lavergne wrote:
> The code comes from a project in which I needed to import from Oracle
> export files into PostgreSQL. I determined the export file format and
> created a parser class. Since the INSERT syntax in Oracle export files
> is based on a parse/bind/execute model, I created second module which
> implements a client-side parse/bind/execute interface to PostgreSQL.
> Also, some syntax is Oracle-specific and needed to be converted (eg.
> DATE->TIMESTAMP), so I created a 3rd module to perform appropriate
> conversions for PostgreSQL.
>
> It become apparent to me that these could form the foundation for the
> TODO of a SQL*Net interface into PostgreSQL since the SQL*Net protocol
> uses a lot of the same constructs found in an export file. Essentially,
> the only pieces missing would be a SQL*Net protocol implementation and
> more comprehensive set of Oracle-like data dictionary views.
>
> I don't mind converting this to C but since the code was not written
> using PostgreSQL coding standards it would take a fair amount of time
> and I want to be certain it's worth the effort. The only built-in C++
> class in the code is the string class in the conversion module and it
> can easily be replaced by a basic C routine. A quick note that the code
> is currently being used on Solaris and Linux so it's at least somewhat
> portable
>
> The question really is do people want an Oracle compatibility layer and
> if yes where should it be in the source tree. Otherwise, I'd be happy to
> contribute it as is, a utility to import Oracle export dumps into
> PostgreSQL.
>
> I'm sure there are people on this list who are indifferent to Oracle
> compatibility. However, a compatibility layer would open the door to
> many existing Oracle applications and more importantly would really ease
> migration to PostgreSQL from Oracle!
>
>
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >
> >>Marc Lavergne <mlavergne-pub(at)richlava(dot)com> writes:
> >>
> >>>never any mention of C++ (libpq++ excepted). So, at a risk of stating
> >>>the obvious (and I'm 99.99% sure I am), does backend code need to be
> >>>submitted as C even if it's for an entirely NEW module?
> >>
> >>Backend code must be C; we do not want to deal with C++ portability
> >>issues.
> >
> >
> > Is it something that could be in /conrib?
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | scott.marlowe | 2002-08-27 17:14:58 | Re: REINDEX ALL and CLUSTER ALL |
Previous Message | Bruce Momjian | 2002-08-27 16:18:13 | Re: REINDEX ALL and CLUSTER ALL |