Re: C vs. C++ contributions - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: C vs. C++ contributions |
Date | |
Msg-id | 200208271633.g7RGXOV28937@candle.pha.pa.us Whole thread Raw |
In response to | Re: C vs. C++ contributions (Marc Lavergne <mlavergne-pub@richlava.com>) |
List | 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@richlava.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@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
pgsql-hackers by date: