Database package

From Octave
Revision as of 10:52, 14 January 2013 by Carandraug (talk | contribs) (import of messages I had on my inbox about database package)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This Octave Forge has currently no maintainer and is known to nor well anymore.


There's another package called osdbi that is released under the BSD license that I was able to make work, but only for sqlite3. You can find it here: JRiedy the author will answer emails. I use it on OS X 10.6 and octave 3.4.0. Also on 10.5.8 but no luck on 10.7


After some hours trying to connect to postgresql, I am geting convinced there is currently no DB connection to postgresql DB from octave. Indeed, there is a very nice small code for mkoctfile:

But, I found there is no longer a libpq++ in postgresql ( Anyone knows if there is a libpqxx interface (I found nothing on google)? In another approach, maybe "extern C" can be used to reimplement a libpq (standard C) based oct of Dirk Eddelbuettel's code?

Embedded SQL

A feature request was open on the tracker to include it as a package.


On 22 December 2011 20:53, Paul Dreik <> wrote:
> 2011-12-21 13:02, dirk skrev:
>> On Wed, 2011-12-21 at 09:34 +0100, Paul Dreik wrote:
>>> 2011-12-20 23:37, skrev:
>>>> Hi all -
>>>> Couldn't make the database package work, and after a reasonable amount
>>>> of googling I concluded I was not the only one.
>>>> As a solution I made my own .oct file that queries SQLite & returns a
>>>> cell array of the results; kudos to  SQLite's "amalgamation" file and
>>>> Octave's "mkoctfile."
>>>> - is this the right forum to ask the next 2 questions?
>>>> - is anyone interested in connecting SQLite to octave?
>>>> - what's my next reasonable step (if any): make a package, post code
>>>> somewhere (here?), or... ?
>>>> thanks,
>>>> dirk mayhew
>>>> ps and thank you also to Xavier Delacour - I would use your code if I could
>>> Hi, no you are certainly not the only one!
>>> I have also made an sqlite octave package, but only for private use. I
>>> think it is wise to discuss on how to implement the interface to such a
>>> toolbox.
>>> * should one mimic the c interface?
>>> * should one mimic the perl dbi interface?
>>> * mimic the matlab database interface?
>>> * make a new one?
>>> What is your opinion?
>>> This is the right place to discuss and send code suggestions.
>>> Paul Dreik
>> Thanks, Paul - those are good questions.
>> I assume by "c interface" you mean ODBC?  I believe that would be best,
>> but requires more work... I suspect this is the direction Xavier took
>> with his database package.
>> Given a choice between perl, Matlab and "create your own," the community
>> would probably prefer a solution that "looks like Matlab." That is,
>> without a GUI and no Matlab-specific I/O, I assume.
>> What do you think?
> No, I mean the sqlite c interface described in
> Using odbc seems to be yet another method to connect. It seems like
> there is an odbc driver for sqlite.
> I know the matlab database toolbox can connect through odbc, that is how
> I used it a few years ago.
> I assembled the list below with my comments and links to documentation.
> I think the matlab database toolbox is a bit messy. It is also quite
> big, so users expecting to use octave database as a dropin replacement
> will probably never be satisfied unless they only use a very basic
> subset. It handles multiple databases, which is good.
> The documentation is at
> I like the relatively clean interface of the sqlite c interface. This is
> how I built my toolbox. (It was a while ago, so I do not remember how
> closely I followed the c interface). Obviously this only supports
> sqlite, so It may be a poor choise for octave database toolbox unless it
> is an octave sqlite toolbox.
> Documentation for api introduction is at
> I also like the perl dbi interface. It handles multiple databases, so it
> may be a good example on how to make an octave interface.
> An easy to read introduction exists at
> I have never worked directly to odbc. Looking at the introductory
> material on
> I say lets stick to any other method...
> The good thing is that it handles multiple databases and it is cross
> platform.
> The existing octave database package seems to offer both a generic
> interface and wrap the database specific apis. I do not know how well it
> performs. Installation failed for me two years ago or so, and it still
> fails now (octave 3.4.2 from macports. See attached errors). I assume I
> do not have all dependencies installed, but the errors seem to point to
> other problems. Have not looked deeper into it.
> I do not know if there are any plans for it or what the current status
> is. Last update on
> (linked to from
> was 2008, but the package was released 2009.
> The swig operations seem like black magic to me.
> I do not currently have the time or need to work on this now, but I am
> willing to share my octave package (sqlite c interface wrapped, more or
> less).

On 23 December 2011 13:42, dirk <> wrote:
> On Wed, 2011-12-21 at 19:56 +0000, Carnë Draug wrote:
>> Are you able to indetify what's broken in the current package?
> I am not calling it broken,  but "difficult to install" or "not
> self-contained" would be fair descriptions.

On 29 December 2011 16:21, dirk <> wrote:
> Unfortunately the file size limit prevented me uploading the required
> sqlite3.c source file; it is available via
> The resulting .oct acts like a dedicated database server.
> Functionally it mimics the existing database "sql" function, but
> *without* the pre-requirements of SWIG & an additional external database
> server oprogram.
> Can anyone can point me to a "beginner's guide to package creation?"
> mkoctfile worked fine for me on Ubuntu and Win7, but I'd guess a tar.gz
> supporting pkg install would be better/cleaner/more useful.