Re: [INTERFACES] mSQL Compatibility Library (fwd)

Added to the contrib directory...I used what you wrote as its README file,
but if you want to brush it up, just submit patches and I'll add it in :)

On Fri, 15 May 1998, Aldrin L. wrote:

> 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(at)americasnet(dot)com>
>

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org