Dirk,
I agree that it would be worthwhile to re-visit what the DBI should
provide, and I
fully agree that R/S-Plus compatibility should not be a goal. Let me
remind you
that the DBI at the time it was defined more than 5 years ago was not meant
to be a complete specification -- it identified m
On 6/2/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Sat, 2 Jun 2007, Tim Keitt wrote:
>
> > On 6/2/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> >> On Sat, 2 Jun 2007, Tim Keitt wrote:
>
> [...]
>
> >> > Edzer's approach is one I've suggested on many occasions -- that we
> >> > subcla
On Sat, 2 Jun 2007, Tim Keitt wrote:
> On 6/2/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>> On Sat, 2 Jun 2007, Tim Keitt wrote:
[...]
>> > Edzer's approach is one I've suggested on many occasions -- that we
>> > subclass the sp classes to act as a proxy to a PostGIS table. I first
>> > de
Brian,
On 2 June 2007 at 19:08, Prof Brian Ripley wrote:
| There are quite a few 'db API' features in RODBC that are not in DBI.
Random idea of the day: Would it be wortwhile to re-think what the DBI API
should cover?
These days, it may matter less to be R and S-Plus compatible [1] but e.g. t
On 6/2/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Sat, 2 Jun 2007, Tim Keitt wrote:
>
> > My Rdbi (+Rdbi.PgSQL) package was written to be much simpler and
> > easier to use than either DBI or RODBC. Unfortunately, I do not have
> > time to maintain it, so I'm not sure what state it is in
On Sat, 2 Jun 2007, Tim Keitt wrote:
> My Rdbi (+Rdbi.PgSQL) package was written to be much simpler and
> easier to use than either DBI or RODBC. Unfortunately, I do not have
> time to maintain it, so I'm not sure what state it is in. Either DBI
> or RODBC should work fine for pushing tables back
