mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-10 05:49:31 +02:00
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. |
||
---|---|---|
.. | ||
Makefile | ||
mpgsql.c | ||
README.mpgsql |
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>