I am working on a rather extensive Oracle compatibility layer that I use 
with PostgreSQL. I am considering contributing the code back to the 
project but the problem is that the layer is currently implemented in 
C++. Simply looking throughout the sources and the dev FAQ, there's 
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?

Thanks,

Marc L.

PS: (Background) The code originally started out as client-side C++ code 
for a project but I'm seeing the value of it for the server side for 
achieving SQL*Net compatibility.



Sun, 21 Jul 2002 15:20:34 -0400
Marc Lavergne <mlavergne-pub@richlava.com>
C vs. C++ contributions
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.

			regards, tom lane

Mon, 22 Jul 2002 11:29:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: C vs. C++ contributions 
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?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 23 Jul 2002 19:16:29 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: C vs. C++ contributions
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?
> 



Wed, 24 Jul 2002 01:00:38 -0400
Marc Lavergne <mlavergne-pub@richlava.com>
Re: C vs. C++ contributions

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, Pennsylvania 19073

Tue, 27 Aug 2002 12:33:24 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
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@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
>>
> 
> 



Tue, 27 Aug 2002 18:24:07 -0400
Marc Lavergne <mlavergne-pub@richlava.com>
Re: C vs. C++ contributions
Marc Lavergne <mlavergne-pub@richlava.com> writes:
> PostgreSQL parse/bind/execute Layer:
> ------------------------------------
> This would be mimicked since PostgreSQL doesn't support it
> natively.

What's stopping you from implementing native support for this? There
will hopefully be an FE/BE protocol change during the 7.4 development
cycle, which should give you the opportunity to make any
protocol-level changes required to implement this properly.

Cheers,

Neil

-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC


27 Aug 2002 18:52:57 -0400
Neil Conway <neilc@samurai.com>
Re: C vs. C++ contributions
That's an quite a bite to chew given my level of experience with 
PostgreSQL internals! However, I will keep it in mind and whatever I do 
will be fully abstracted (already is actually) so that it should just a 
matter of snapping it into place when 7.4 forks. Realistically, I can't 
comment from an informed position on this yet. When I get a chance to 
look into what is happening in 7.3 and the 7.4 roadmap, I will post back 
if I feel I can provide something of substance.

Cheers,

Marc

Neil Conway wrote:
> Marc Lavergne <mlavergne-pub@richlava.com> writes:
> 
>>PostgreSQL parse/bind/execute Layer:
>>------------------------------------
>>This would be mimicked since PostgreSQL doesn't support it
>>natively.
> 
> 
> What's stopping you from implementing native support for this? There
> will hopefully be an FE/BE protocol change during the 7.4 development
> cycle, which should give you the opportunity to make any
> protocol-level changes required to implement this properly.
> 
> Cheers,
> 
> Neil
> 



Wed, 28 Aug 2002 00:39:03 -0400
Marc Lavergne <mlavergne-pub@richlava.com>
Re: C vs. C++ contributions
Marc Lavergne writes:

> This covers a few different sub-projects so I'm breaking it down in
> order of how I'm going to attack it.

Just to give you a fair warning:  I'm not going to be in favor of adding
any "Oracle compatibility" functionality that overlaps with existing
and/or standardized functionality.  That kind of thing would lock us into
an endless catch-up game and would induce users to code their applications
to proprietary interfaces.

I suppose some of the things you propose would be external applications,
such as the export file reader or the SQL*Net proxy.  The synonym
functionality would be interesting to add, since there is no existing
feature of that type.  But random misfeatures such as the join syntax or
the decode() function are going to have a hard time getting accepted.

-- 
Peter Eisentraut   peter_e@gmx.net


Wed, 28 Aug 2002 20:27:45 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: C vs. C++ contributions
Peter Eisentraut wrote:
> Marc Lavergne writes:
> 
> > This covers a few different sub-projects so I'm breaking it down in
> > order of how I'm going to attack it.
> 
> Just to give you a fair warning:  I'm not going to be in favor of adding
> any "Oracle compatibility" functionality that overlaps with existing
> and/or standardized functionality.  That kind of thing would lock us into
> an endless catch-up game and would induce users to code their applications
> to proprietary interfaces.

I think some of the Oracle stuff will have to be turned on to be
enabled, others of it can be on by default.

> I suppose some of the things you propose would be external applications,
> such as the export file reader or the SQL*Net proxy.  The synonym
> functionality would be interesting to add, since there is no existing
> feature of that type.  But random misfeatures such as the join syntax or
> the decode() function are going to have a hard time getting accepted.

But we have decode():

	test=> \df decode
	                      List of functions
	 Result data type |   Schema   |  Name  | Argument data types 
	------------------+------------+--------+---------------------
	 bytea            | pg_catalog | decode | text, text
	(1 row)

Is this a different decode?

-- 
  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, Pennsylvania 19073

Wed, 28 Aug 2002 15:03:13 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: C vs. C++ contributions
 >> But we have decode():

It is a different decode function, more akin to "case when".

 >> Just to give you a fair warning:  I'm not going to be in favor of 
adding any "Oracle compatibility" functionality that overlaps with 
existing and/or standardized functionality.

I wouldn't even dream of it. The last thing I want to do is turn 
PostgreSQL into an Oracle clone. My aim is to provide a simplified 
migration path from Oracle and to implement basic compatibility to 
enable interoperability between the two DBs.

Bruce Momjian wrote:
> Peter Eisentraut wrote:
> 
>>Marc Lavergne writes:
>>
>>
>>>This covers a few different sub-projects so I'm breaking it down in
>>>order of how I'm going to attack it.
>>
>>Just to give you a fair warning:  I'm not going to be in favor of adding
>>any "Oracle compatibility" functionality that overlaps with existing
>>and/or standardized functionality.  That kind of thing would lock us into
>>an endless catch-up game and would induce users to code their applications
>>to proprietary interfaces.
> 
> 
> I think some of the Oracle stuff will have to be turned on to be
> enabled, others of it can be on by default.
> 
> 
>>I suppose some of the things you propose would be external applications,
>>such as the export file reader or the SQL*Net proxy.  The synonym
>>functionality would be interesting to add, since there is no existing
>>feature of that type.  But random misfeatures such as the join syntax or
>>the decode() function are going to have a hard time getting accepted.
> 
> 
> But we have decode():
> 
> 	test=> \df decode
> 	                      List of functions
> 	 Result data type |   Schema   |  Name  | Argument data types 
> 	------------------+------------+--------+---------------------
> 	 bytea            | pg_catalog | decode | text, text
> 	(1 row)
> 
> Is this a different decode?
> 



Wed, 28 Aug 2002 17:05:22 -0400
Marc Lavergne <mlavergne-pub@richlava.com>
Re: C vs. C++ contributions
> > feature of that type.  But random misfeatures such as the join syntax or
> > the decode() function are going to have a hard time getting accepted.
>
> But we have decode():
>
> 	test=> \df decode
> 	                      List of functions
> 	 Result data type |   Schema   |  Name  | Argument data types
> 	------------------+------------+--------+---------------------
> 	 bytea            | pg_catalog | decode | text, text
> 	(1 row)
>
> Is this a different decode?

Yes this is completly different. Oracle decode works like this:

decode(value, choice1, result1, choice 2, result2, ......, default_result)

it works this way:
case 
  when value=choice1 then result1
  when value=choice2 then result2
  ....
  else
  default_result
end

The nice part is it has an varying number of arguments, and can used within "sort". Very useful sometimes.

Another one very useful oracle function is "nvl", the same like "coalesce", but a lot easier to write :-)



Thu, 29 Aug 2002 08:57:06 +0200
Mario Weilguni <mweilguni@sime.com>
Re: C vs. C++ contributions
Mario Weilguni wrote:
> Yes this is completly different. Oracle decode works like this:
> 
> decode(value, choice1, result1, choice 2, result2, ......,
> default_result)
> 
> it works this way:  case
>   when value=choice1 then result1 when value=choice2 then result2
>   ....
>   else default_result end

Yes, it would be nice to be able turn these on just for portability with
Oracle queries.

> The nice part is it has an varying number of arguments, and can
> used within "sort". Very useful sometimes.

With our CASE, you create a column using the CASE, then ODER BY on that
column.

> Another one very useful oracle function is "nvl", the same like
> "coalesce", but a lot easier to write :-)

Yes, another nice portability thing if it could be enabled/disabled.

--
  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, Pennsylvania 19073

Thu, 29 Aug 2002 14:32:31 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: C vs. C++ contributions
> > The nice part is it has an varying number of arguments, and can
> > used within "sort". Very useful sometimes.
>
> With our CASE, you create a column using the CASE, then ODER BY on that
> column.

Not exactly, you have to create a column for this, and it will be in the select list. Oracle does not need this.

Fri, 30 Aug 2002 07:59:40 +0200
Mario Weilguni <mweilguni@sime.com>
Re: C vs. C++ contributions
Marc Lavergne wrote:
> That's an quite a bite to chew given my level of experience with 
> PostgreSQL internals! However, I will keep it in mind and whatever I do 
> will be fully abstracted (already is actually) so that it should just a 
> matter of snapping it into place when 7.4 forks. Realistically, I can't 
> comment from an informed position on this yet. When I get a chance to 
> look into what is happening in 7.3 and the 7.4 roadmap, I will post back 
> if I feel I can provide something of substance.

FYI, we just split off 7.4 so we are ready to accept 7.4 patches.

-- 
  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, Pennsylvania 19073

Sat, 28 Sep 2002 22:09:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: C vs. C++ contributions