Feature request: dbWriteTable Greenplum support

[GoogleCodeExporter]

Very table in greenplum must be creaed with as distributed by(col1,...) cluase, 
can you add a parameter to the current dbWriteTable function to support 
Greenplum, such as

dbWriteTable(...., disCol=c("col1","col2"));

Then the table will be created as 

Create table t(...) distribued by(col1,col2);

Original issue reported on code.google.com by guxiaobo...@gmail.com on 19 Nov 2011 at 1:13

[GoogleCodeExporter]

That is very tough as we do not have access to Greenplum!

Can you work on a patch, we ship the patch as a contributed patch in the 
package?

Original comment by dirk.eddelbuettel on 19 Nov 2011 at 1:43

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

You can use their community version, it's free.
http://www.greenplum.com/community/downloads/database-ce/

Original comment by guxiaobo...@gmail.com on 20 Nov 2011 at 3:48

[GoogleCodeExporter]

Hi, please see the attached file.

Original comment by guxiaobo...@gmail.com on 24 Nov 2011 at 8:46

Attachments:

• dbwritetable.r

[GoogleCodeExporter]

Can you help to merge this into trunk please, I have tested it.

Original comment by guxiaobo...@gmail.com on 8 Jan 2012 at 3:06

[GoogleCodeExporter]

I don't think we will merge this non-standard feature in near future.
The first priority is to make the code standard conforming and concise that is 
readable.
Current code has strange automatically opening new connection code. This means
we cannot trust the connection is the same one and thus transaction cannot be 
used.

Furthermore, Greenplum is not free (in liberty) and automatic test cannot be 
configured.
A proper test code and document must present to be considered for a merge but 
you can not write a good test. (Not because of your capability but because 
Greenplum is not setup in most developing environment).

More simply, Greenplum is not PostgreSQL and thus it is not in my scope.

Original comment by tomoa...@kenroku.kanazawa-u.ac.jp on 10 Jan 2012 at 9:17

[GoogleCodeExporter]

>I don't think we will merge this non-standard feature in near future.
>The first priority is to make the code standard conforming and concise that is 
>readable.
PostgreSQL related technolege is not a standard, it's just a specific software, 
and we can revise the code to be more readable if you don't think it is 
currently.

>Current code has strange automatically opening new connection code. This means
>we cannot trust the connection is the same one and thus transaction cannot be 
used.
I don't know why you mention this, it is a problem of the RPostgreSQL itself, 
regardless which backend do you use, postgreSQL or greenplum.

>Furthermore, Greenplum is not free (in liberty) and automatic test cannot be 
>configured.
Greenplum community edition is free, and we can just use the PostgreSQL client 
library to  build RPostgreSQL, thus automatic test can be configured.

>A proper test code and document must present to be considered for a merge but 
you >can not write a good test. (Not because of your capability but because 
Greenplum is >not setup in most developing environment).
We can use the free version, and the installation process is very simple, I can 
attach a guide here if you want.

>More simply, Greenplum is not PostgreSQL and thus it is not in my scope.
Greenplum is a new technowlege, it's line compatible with PostgreSQL, why don't 
let RPostgreSQL support it. From my experience,  why I start using RPostgreSQL 
and willing to contribute to it just because I want RPostgreSQL to work with 
Greenplum.

Original comment by guxiaobo...@gmail.com on 10 Jan 2012 at 12:01

[GoogleCodeExporter]

> PostgreSQL related technolege is not a standard,
For RPostgreSQL, the PostgreSQL and the DBI are the standard.

>I don't know why you mention this, it is a problem of the RPostgreSQL itself,

What I am saying is that RPostgreSQL is not yet in a phase that
we can add extra features, which complicate the refactoring or code cleaning.
There are plenty of TODOs before considering this feature.
Note, I didn't write anything on your code nor did I write it will never merged.
But it will not happen soon.

The license of greenplum 
http://info.greenplum.com/software-terms-and-conditions.html
is far from free and I have no plan to deal with it any further.
It is not a matter of a guide.

If you need to change something for greenplum, it means that
Greenplum is not compatible with PostgreSQL.  That's all.

There are quite a lot of derivatives and no reason to specifically support 
greenplum.
http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connection_Pool
ing
http://postgres-xc.sourceforge.net/

Original comment by tomoa...@kenroku.kanazawa-u.ac.jp on 10 Jan 2012 at 3:56

[GoogleCodeExporter]

>What I am saying is that RPostgreSQL is not yet in a phase that
>we can add extra features, which complicate the refactoring or code cleaning.
>There are plenty of TODOs before considering this feature.
>Note, I didn't write anything on your code nor did I write it will never 
merged.
>But it will not happen soon.
But I have finished the work, what you have to is simply merging it into trunk.

>The license of greenplum 
>http://info.greenplum.com/software-terms-and-conditions.html
>is far from free and I have no plan to deal with it any further.
>It is not a matter of a guide.
If you use it in a single node with less than 2 CPUs, it is free even for 
production, and we don't have redistribute it, we even don't have to install it 
when building RPostgreSQL.

>>If you need to change something for greenplum, it means that
>>Greenplum is not compatible with PostgreSQL.  That's all.
The current writeTable function works against Greenplum, but there is warning, 
if we add the advanced parameter it will be perfect.

>There are quite a lot of derivatives and no reason to specifically support 
>greenplum.
>http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connection_Poo
ling
>http://postgres-xc.sourceforge.net/

I think it's because of nobody has the demand to use RPostgreSQL against them.

Original comment by guxiaobo...@gmail.com on 12 Jan 2012 at 11:48

[GoogleCodeExporter]

Original comment by tomoa...@kenroku.kanazawa-u.ac.jp on 25 Jun 2013 at 6:03

• Changed state: WontFix