Issue 35 in rpostgresql: Feature request: dbWriteTable Greenplum support
rpost...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 35 by guxiaobo...@gmail.com: Feature request: dbWriteTable
Greenplum support
http://code.google.com/p/rpostgresql/issues/detail?id=35
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);
rpost...@googlecode.com
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low
Comment #1 on issue 35 by dirk.eddelbuettel: Feature request: dbWriteTable
Greenplum support
http://code.google.com/p/rpostgresql/issues/detail?id=35
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?
rpost...@googlecode.com
Comment #2 on issue 35 by guxiaobo...@gmail.com: Feature request:
http://code.google.com/p/rpostgresql/issues/detail?id=35
You can use their community version, it's free.
http://www.greenplum.com/community/downloads/database-ce/
rpost...@googlecode.com
Comment #3 on issue 35 by guxiaobo...@gmail.com: Feature request:
http://code.google.com/p/rpostgresql/issues/detail?id=35
Hi, please see the attached file.
Attachments:
dbwritetable.r 4.0 KB
rpost...@googlecode.com
Comment #4 on issue 35 by guxiaobo...@gmail.com: Feature request:
http://code.google.com/p/rpostgresql/issues/detail?id=35
Can you help to merge this into trunk please, I have tested it.
rpost...@googlecode.com
Comment #5 on issue 35 by tomoa...@kenroku.kanazawa-u.ac.jp: Feature
http://code.google.com/p/rpostgresql/issues/detail?id=35
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.
rpost...@googlecode.com
Comment #6 on issue 35 by guxiaobo...@gmail.com: Feature request:
http://code.google.com/p/rpostgresql/issues/detail?id=35
> 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.
Dirk Eddelbuettel
On 10 January 2012 at 12:01, rpost...@googlecode.com wrote:
[...]|
| client library to build RPostgreSQL, thus automatic test can be configured.
| 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.
Please feel free to fork RPostgreSQL to form your own RGreenplum project.
We have been very clear to you that we have no interest in supporting a
commercial extension that could never be on CRAN for lack of sources. And we
have told you so repeatedly.
Also note that we don't do REntrepriseDB or other Pg extensions either. This
is RPostgreSQL, and we support a connection package between the standard open
source packages GNU R and PostgreSQL.
Thanks, Dirk
--
"Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
dark to read." -- Groucho Marx
rpost...@googlecode.com
Comment #7 on issue 35 by tomoa...@kenroku.kanazawa-u.ac.jp: Feature
http://code.google.com/p/rpostgresql/issues/detail?id=35
> 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_Pooling
http://postgres-xc.sourceforge.net/
rpost...@googlecode.com
Comment #8 on issue 35 by guxiaobo...@gmail.com: Feature request:
http://code.google.com/p/rpostgresql/issues/detail?id=35
> 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_Pooling
> http://postgres-xc.sourceforge.net/
I think it's because of nobody has the demand to use RPostgreSQL against
them.
rpost...@googlecode.com
Status: WontFix
Comment #9 on issue 35 by tomoa...@kenroku.kanazawa-u.ac.jp: Feature
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings