Re: new postgresql package

[Olaf Till]

On Sat, Jan 12, 2013 at 11:42:24AM -0500, Michael Goffioul wrote:
> On Sat, Jan 12, 2013 at 10:12 AM, Olaf Till <address@hidden> wrote:
> 
> > On Sat, Jan 12, 2013 at 01:58:41PM +0100, Juan Pablo Carbajal wrote:
> > > <snip>
> > > It is possible to add your package as a subfolder of database (check
> > > geometry and octclip). We do not have subpackages yet. Of course, if
> > > you prefer to have it as an independent package I am not against it,
> > > this is just a suggestion.
> >
> > Indeed I would not like to mix maintained code with unmaintained in
> > one package.
> >
> 
> To be honest, I would much prefer to have a single database package, than a
> package for postgresql, one for mysql, one for sqlite, one for odbc, one
> for... The multiplication of niche packages does not benefit the end user
> IMO.
> 
> The current database package is broken and unmaintained. My suggestion
> would then be to drop the existing database package, and design yours such
> that you have a common interface and multiple backends. At the beginning,
> there would be only one postgresql backend. Nobody asks you to support the
> other database systems. But at least, there would be a common ground for
> someone to implement other backends.
>
> <snip>

I understand the point. But in my package I try to exploit the
functionality of the postgresql interface library and server in the
best possible way. This has implications for the user interface of the
package. E.g. the packages knowledge of defined postgresql types has
to be updated if types are defined or dropped during the
connection. For this there is a special user function, which probably
could not be part of a common interface for all database systems. From
this example you can see that even for designing the interface, if it
strives to exploit all functionality, one has to thoroughly know the
interface library and other peculiarities of the respective database
system. This knowledge I do not have in the least for mysql and sqlite
(and odbc). I can not foresee what special user functions could be
necessary for the other systems and if a common interface which yet
exploits all functionality is at all feasible.

In any case designing such a common interface would be a major effort
which I am not ready to undertake. It would also have an impact on the
internals of my package. E.g. in cases where the user has to specify
types of passed parameters, I decided that he has to use postgresqls
internal type names. But these are not in all cases typenames of
standard sql, so I would have to introduce a level of name mapping.

Also, even if there would be a common interface, the way to use it
could be different for different systems except for simple tasks. So
I'm not sure the effort would be justified, even if I was ready to
undertake it. A weaker solution could be to collect functions for
different database systems within one package (as long as a maintainer
is found for each database system) but to do this independently of a
common interface function. Indeed I anticipated such a way when giving
the function for setting options (which was just copied from Octaves
optimset) the name setdbopts, not setpqopts. If indeed a contributor
and maintainer is found for another database system, there is still
the possibility to implement a common interface, limiting the
available functionality, afterwards in the form of a wrapper.

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature