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

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

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:

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

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

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

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

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:

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 :-)

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

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.

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