Thread: C vs. C++ contributions
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.
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, Pennsylvania19026
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? >
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
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, ispretty 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 >> > >
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 <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 >
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, Pennsylvania19073
>> 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? >
> > 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, Pennsylvania19073
> > 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, Pennsylvania19073