octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new postgresql package


From: Olaf Till
Subject: Re: new postgresql package
Date: Tue, 15 Jan 2013 18:35:21 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Jan 14, 2013 at 06:54:36PM +0000, Carnë Draug wrote:
> On 13 January 2013 18:46, Olaf Till <address@hidden> wrote:
> > Well, then I'll try to review the database package more thoroughly
> > before I decide on a possible code coexistence within it.
> 
> I had a bunch of e-mails on my inbox about the database package
> marked. Mostly attempts to fix it and their records. One of them was
> about postgreSQL. I have pasted them all on the wiki at
> http://wiki.octave.org/Database_package maybe they will be useful.

Thanks. They seem to agree with my impression.

I could not get database to compile, even with moderate changes (which
actually are not supposed to be made at all) to the generated
'postgres_wrap.cpp' file. One of the reasons seems to be the
incompatibility of my SWIG version with current (3.6.2) Octave
API. Maybe a more recent SWIG would work. But:

With this design, SWIG does much of the work, and we depend on
SWIG. I.e. we can't fix some bugs, but have to wait till SWIG is fixed
(and remember that the Octave API is evolving!). This can't be the way
to go for an Octave package, at least if it can be avoided.

According a.o. to 'postgres_wrap.cpp', SWIG seems to do (disclaimer:
have only shortly glanced at SWIG documentation and could not test by
compiling 'database') some interesting things: deriving an extra
octave_value type, treating it as 'passed by reference' by
circumventing 'const', generating user interface functions. This is
partially similar to what we do e.g. in the instrument-control package
(as Carlo pointed out to me) and also in my new package. In the
database package, this would spare (if it worked) relatively much
programming work. But in a more specialized package with a bit more
thourough usage of the SQL-systems capabilities, the main part of the
programming work is in programming the SQL-system anyway, so it does
not hurt to program the user-interface part by oneself.

So I'd agree with Michael Goffioul that the (contents of the) database
package should be removed. And we should not use SWIG for it again.

At least I naturally can't place my package side by side with the
current 'database' code. (Another --- weaker --- reason would be that
I'd have to rewrite the configure system without knowing the
motivation of all configure-tests contained in 'database'.)

Since you left it to me, I'll make a new package
'database-postgresql', so the code will be available for
inspection. But this does not mean that I'd object to place it within
a common database package, with the possibility that a common
interface is designed _after_ other database-systems are added by
others. If you should decide to clean out the old 'database' package,
I could move my code if you like.

Olaf


P.S:

It seems that in 'database' SWIG is supposed to generate, additionally
to the central high-level function, some low-level interface functions
from postgresqls header files. I can't imagine how it can be safe to
expose these functions to the user. How can SWIG determine if such a
function frees memory, so it has to avoid to call it more than once?
PQclear, e.g. is provided and seems not marked special in the included
adapted postgresql header file.

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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]