Op di 13 december 2011 om 15:35:14 (+0100) schreef rehs...@googlemail.com (Jens
Rehsack):
2011/10/4 Reinier Post r...@win.tue.nl:
[...]
For instance, I have a simple script that needs to count the number of
distinct values in columns. This seems like a pretty elementary thing
to do, but
2011/10/4 Reinier Post r...@win.tue.nl:
On Fri, Sep 23, 2011 at 11:19:32PM -0400, Brendan Byrd wrote:
[...], the Perl community in general needs this. Developers need to just
grab some modules via CPAN, describe the relational models (if they don't
already exist), and have the flow of data
On Fri, Sep 23, 2011 at 11:19:32PM -0400, Brendan Byrd wrote:
[...], the Perl community in general needs this. Developers need to just
grab some modules via CPAN, describe the relational models (if they don't
already exist), and have the flow of data *just work!* [...]
I would love to have
On Tue, Oct 04, 2011 at 02:20:10PM +0200, Reinier Post wrote:
On Fri, Sep 23, 2011 at 11:19:32PM -0400, Brendan Byrd wrote:
For a start it would be nice to have a matrix up somewhere listing
DBMSes against SQL constructs, so I can look up, for instance, against
which types of DBD backends
On Sat, Sep 24, 2011 at 12:30 AM, Darren Duncan dar...@darrenduncan.netwrote:
Brendan Byrd wrote:
Yeah, that sounds right. So would this eventually become its own DBD
module?
Yes and no. It would not natively be a DBD module, but a separate module
can exist that is a DBD module which
The problem with PostgreSQL's SQL/MED is that it's not Perl, and it won't
work for some of the more abstract objects available as DBD. I would like
to tie this DBD::FederatedDB into DBIC, so that it can search and insert
everything on-the-fly. Shoving everything into RAM isn't right, either,
On Fri, Sep 23, 2011 at 5:01 PM, Darren Duncan dar...@darrenduncan.netwrote:
The problem with PostgreSQL's SQL/MED is that it's not Perl, and it won't
work for some of the more abstract objects available as DBD.
You may want to look into PL/Perl then, using Perl inside Postgres, to
bring
I only got a copy of this message directly and not also via the list as
expected, since you addressed it to the list, but anyway ...
Brendan Byrd wrote on 2011 Sep 22 at 6:25am PST/UTC-8:
The problem with PostgreSQL's SQL/MED is that it's not Perl, and it
won't work for some of the more
Brendan Byrd wrote:
On Fri, Sep 23, 2011 at 5:01 PM, Darren Duncan dar...@darrenduncan.net wrote:
This essentially is exactly what you want to do, have a common query
syntax where behind the scenes some is turned into SQL that is
pushed to back-end DBMSs, and some of which is turned
Okay, this is a big blue sky idea, but like all things open-source, it comes
out of a need. I'm trying to merge together Excel (or CSV), Oracle, Fusion
Tables, JSON, and SNMP for various data points and outputs. DBIC seems to
work great for a large database with a bunch of tables, but what about
On Sep 21, 2011, at 7:53 PM, Brendan Byrd wrote:
Okay, this is a big blue sky idea, but like all things open-source, it comes
out of a need. I'm trying to merge together Excel (or CSV), Oracle, Fusion
Tables, JSON, and SNMP for various data points and outputs. DBIC seems to
work great for a
Brendan,
Taking into account David's response ...
I have several answers for you:
1. The functionality you are talking about is often referred to as a federated
database, where you have one database engine that the client talks to which
turns around and farms some of the work off to various
12 matches
Mail list logo
