Thread: Matlab Mex Interface
We have recently developed an interface to PostgreSQL for Matlab. The interface is implemented as 'C' mex wrappers around libpq. Most of the database connection and query execution functions are implemented, and it supports default (text) and binary transfers directly into Matlab variables (including text, integer, and floating point arrays). The functions have been tested on Linux, SGI 32 bit, and Windows architectures. Other architectures should be trivial to support - just a matter of compiling. We would like to make this interface freely available, and would like to know how much interest there would be in the interface. Also, would it be worthwhile to package and make available with PostgreSQL. Any comments? Darrin Rothe Arizona State University rothe@asu.edu
On Fri, 13 Oct 2000, Darrin Rothe wrote: > We have recently developed an interface to PostgreSQL for Matlab. > > The interface is implemented as 'C' mex wrappers around libpq. Most of the > database connection and query execution functions are implemented, and it > supports default (text) and binary transfers directly into Matlab variables > (including text, integer, and floating point arrays). > > The functions have been tested on Linux, SGI 32 bit, and Windows > architectures. Other architectures should be trivial to support - just a > matter of compiling. > > We would like to make this interface freely available, and would like to > know how much interest there would be in the interface. Also, would it be > worthwhile to package and make available with PostgreSQL. the only problem that I could see with this is the license that it is under ... if under BSD license, we could easily extend configure to have a --with-matlab option ...
Licensing shouldn't be an issue. I have permission from the university to release it into "the public domain." However, I intend to attach the BSD style license/disclaimer which exists with PostgreSQL. Matlab's license does not impose any restrictions on programs written using their API. However, to compile the routines, one would need Matlab installed in order to pick up some of their header files. Darrin Rothe rothe@asu.edu > -----Original Message----- > From: The Hermit Hacker [mailto:scrappy@hub.org] > Sent: Friday, October 13, 2000 8:58 PM > To: Darrin Rothe > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Matlab Mex Interface > > > On Fri, 13 Oct 2000, Darrin Rothe wrote: > > > We have recently developed an interface to PostgreSQL for Matlab. > > > > The interface is implemented as 'C' mex wrappers around libpq. > Most of the > > database connection and query execution functions are > implemented, and it > > supports default (text) and binary transfers directly into > Matlab variables > > (including text, integer, and floating point arrays). > > > > The functions have been tested on Linux, SGI 32 bit, and Windows > > architectures. Other architectures should be trivial to > support - just a > > matter of compiling. > > > > We would like to make this interface freely available, and would like to > > know how much interest there would be in the interface. Also, > would it be > > worthwhile to package and make available with PostgreSQL. > > the only problem that I could see with this is the license that it is > under ... if under BSD license, we could easily extend configure to have a > --with-matlab option ... > > >
On Fri, 13 Oct 2000, Darrin Rothe wrote:
> Licensing shouldn't be an issue. I have permission from the university to
> release it into "the public domain." However, I intend to attach the BSD
> style license/disclaimer which exists with PostgreSQL. Matlab's license
> does not impose any restrictions on programs written using their API.
> However, to compile the routines, one would need Matlab installed in order
> to pick up some of their header files.
that's okay ... PyGreSQL needs Python, Perl needs perl, etc
... requirements won't limit its ability to be included, only licensing :)
>
> Darrin Rothe
> rothe@asu.edu
>
>
> > -----Original Message-----
> > From: The Hermit Hacker [mailto:scrappy@hub.org]
> > Sent: Friday, October 13, 2000 8:58 PM
> > To: Darrin Rothe
> > Cc: pgsql-general@postgresql.org
> > Subject: Re: [GENERAL] Matlab Mex Interface
> >
> >
> > On Fri, 13 Oct 2000, Darrin Rothe wrote:
> >
> > > We have recently developed an interface to PostgreSQL for Matlab.
> > >
> > > The interface is implemented as 'C' mex wrappers around libpq.
> > Most of the
> > > database connection and query execution functions are
> > implemented, and it
> > > supports default (text) and binary transfers directly into
> > Matlab variables
> > > (including text, integer, and floating point arrays).
> > >
> > > The functions have been tested on Linux, SGI 32 bit, and Windows
> > > architectures. Other architectures should be trivial to
> > support - just a
> > > matter of compiling.
> > >
> > > We would like to make this interface freely available, and would like to
> > > know how much interest there would be in the interface. Also,
> > would it be
> > > worthwhile to package and make available with PostgreSQL.
> >
> > the only problem that I could see with this is the license that it is
> > under ... if under BSD license, we could easily extend configure to have a
> > --with-matlab option ...
> >
> >
> >
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
"Darrin Rothe" <rothe@asu.edu> writes:
> We have recently developed an interface to PostgreSQL for Matlab.
> ...
> We would like to make this interface freely available, and would like to
> know how much interest there would be in the interface. Also, would it be
> worthwhile to package and make available with PostgreSQL.
Sounds pretty cool to me!
As for distribution, you could either stick it up on a website of your
own, or submit it for inclusion in the Postgres distribution. There
are two possible levels of inclusion in the distro: as a contrib package
or as a main-tree interface subdirectory. The difference is that contrib
packages are never built by default, and so armed core members are not
going to show up on your doorstep if the thing doesn't build on some
random platform ;-). If you want to go for main-tree status, you had
better be prepared to answer the bell when there's a problem. A possible
compromise is contrib now with hopes of being integrated into the main
tree after a shakedown period.
Also, we'd really like straight BSD license for anything included in
the distribution, whereas if you distribute it separately you can use
GPL or whatever you like.
This project seems worthwhile enough to me that you should let it out
on some terms. Your choice what license terms to use and how much
support commitment you want to make. Let us know.
regards, tom lane