Re: C vs. C++ contributions

This covers a few different sub-projects so I'm breaking it down in
order of how I'm going to attack it. The TTC estimates are going to vary
based on my bandwidth which, unfortunately, is pretty tight right now.
However, there is relief on the horizon and I do have a vested interest
in getting this completed, so here goes:

SYNONYM functionality:
----------------------
I need to create a patch for SYNONYM like functionality against 7.2.2
(and 7.3). This is a very high priority for me right now. This can't be
a simple mimic using views, it has to be a true synonym mechanism. This
may require a significant amount of work.

TTC: mid/end-September

PostgreSQL parse/bind/execute Layer:
------------------------------------
This would be mimicked since PostgreSQL doesn't support it natively.
It's needed because most Oracle based code (and certainly export files)
expect the data to be processed in this manner. I essentially already
have this done but the code for it is in C++ so I just need to convert.
This is currently a client side extension.

TTC: end-September

Oracle Export File Reader:
--------------------------
I am going to convert my code to C and offer it up. It's already posted
on Gborg in C++ form but I see the benefit of moving it to C. This is
already written so it's only a matter of repackaging it. Note that this
requires several emulated Oracle features.

TTC: mid-October

Oracle Compatibility Layer:
---------------------------
Has to be attacked in stages due to the large number of Oracle
extensions to SQL. I would guess that Oracle JOIN syntax would be first
on my list (I'm thinking of just doing syntax expansion), followed by
Oracle data dictionary compatibility (this is already mostly completed).
There are also some commonly used Oracle functions that need to be
duplicated by name (ie. decode -> case).

TTC: end-October

SQL*Net Compatibility:
----------------------
This is a much nastier (but more interesting) piece of work. This will
require implementing a virtual Oracle SQL*Net listener. I've done some
work like this on the client side but never on the server side. It's
certainly doable and I already know how I want to approach this. I don't
expect much trouble getting this to work under extremely controlled
conditions. However, getting this to a workable state for general use is
really an unknown right now.

TTC: end-December???

So in brief, I haven't abandoned the plan, I just haven't had the
bandwidth to get back on it. I'm hoping to be able to commit some time
to this very shorty.

Cheers,

Marc L.

Bruce Momjian wrote:
> 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
>>
>
>