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?
>