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:

Previous
From: Bruce Momjian
Date:
Subject: Re: REINDEX ALL and CLUSTER ALL
Next
From: "scott.marlowe"
Date:
Subject: Re: REINDEX ALL and CLUSTER ALL