66eb8df6a4
snprintf() in contrib/. I didn't touch the places where pointer arithmatic was being used, or other areas where the fix wasn't trivial. I would think that few, if any, of the usages of sprintf() were actually exploitable, but it's probably better to be paranoid... Neil Conway |
||
---|---|---|
.. | ||
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>