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 ...
RE: [GENERAL] Matlab Mex Interface
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
[EMAIL PROTECTED]
-Original Message-
From: The Hermit Hacker [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 13, 2000 8:58 PM
To: Darrin Rothe
Cc: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [GENERAL] Matlab Mex Interface
"Darrin Rothe" [EMAIL PROTECTED] 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
