postgresql/contrib/mSQL-interface
Peter Eisentraut 805e431a38 Add support for VPATH builds, that is, building somewhere else than in the
source directory.  This involves mostly makefiles using $(srcdir) when they
might have used ".".  (Regression tests don't work with this, yet.)

Sort out usage of CPPFLAGS, CFLAGS (and CXXFLAGS).  Add "override" keyword
in most places, to preserve necessary flags even when the user overrode the
flags.
2000-10-20 21:04:27 +00:00
..
Makefile Add support for VPATH builds, that is, building somewhere else than in the 2000-10-20 21:04:27 +00:00
mpgsql.c
README.mpgsql Add missing /contrib files 2000-06-19 14:02:16 +00:00

Hello! :)

(Sorry for my english. But if i wrote in portuguese, you wouldn't
 understand nothing. :])

	I found it's the right place to post this. I'm a newcomer in these
lists. I hope i did it right. :]

<BOREDOM>
	When i started using SQL, i started with mSQL. I developed a lot
of useful apps for me and my job with C, mainly because i loved it's
elegant, simple api. But for a large project i'm doing in these days, i
thought is was not enough, because it felt a lot of features i started to
need, like security and subselects. (and it's not free :))
	So after looking at the options, choose to start again with
postgres. It offered everything that i needed, and the documentation is
really good (remember me to thank the one who wrote'em).
	But for my little apps, i needed to start porting them to libpq.
After looking at pq's syntax, i found it was better to write a bridge
between the mSQL api and libpq. I found that rewriting the libmsql.a
routines that calls libpq would made things much easier. I guess the
results are quite good right now.
</BOREDOM>

	Ok. Lets' summarize it:

	mpgsql.c is the bridge. Acting as a wrapper, it's really good,
since i could run mSQL. But it's not accurate. Some highlights:

	CONS:
	* It's not well documented 
		(this post is it's first documentation attempt, in fact);
	* It doesn't handle field types correctly. I plan to fix it,
	  if people start doing feedbacks;
	* It's limited to 10 simultaneous connections. I plan to enhance
	  this, i'm just figuring out;
	* I'd like to make it reentrant/thread safe, although i don't
	  think this could be done without changing the API structure;
	* Error Management should be better. This is my first priority
          now;
	* Some calls are just empty implementations.

	PROS:
	* the mSQL Monitor runs Okay. :]
	* It's really cool. :)
	* Make mSQL-made applications compatible with postgresql just by
	  changing link options.
	* Uses postgreSQL. :]
	* the mSQL API it's far easier to use and understand than libpq.
          Consider this example:

#include "msql.h"

void main(int argc, char **argv, char **envp) {
   int sid;
	
   sid = msqlConnect(NULL); /* Connects via unix socket */

   if (sid >= 0) {
      m_result *rlt;
      m_row *row;
      msqlSelectDB(sid, "hosts");
      if (msqlQuery(sid, "select host_id from hosts")) {
	 rlt = msqlStoreResult();
         while (row = (m_row*)msqlFetchRow(rlt)) 
            printf("hostid: %s\n", row[0]);
         msqlFreeResult(rlt);
      }
      msqlClose(sid);
   }
}

	I enclose mpgsql.c inside. I'd like to maintain it, and (maybe, am
i dreaming) make it as part of the pgsql distribution. I guess it doesn't
depends on me, but mainly on it's acceptance by its users.

	Hm... i forgot: you'll need a msql.h copy, since it's copyrighted
by Hughes Technologies Pty Ltd. If you haven't it yes, fetch one
from www.hughes.com.au.

	I would like to catch users ideas. My next goal is to add better
error handling, and to make it better documented, and try to let relshow
run through it. :)

	done. Aldrin Leal <aldrin@americasnet.com>