> Contributions are always welcome :-)
Great! I come from the pgsql world so my observations are on the main code +
pgsql backend.
> Could you give me an overview of what you think what should be changed
> or improved?
All my remarks are questions rather than affirmations:
_ The use of malloc may be prevented, by requesting a odbx_t* instead than
odbx_t**. The allocation on the stack will thus reduce processor cache misses.
_ Putting the addresses of backend functions in a structure is risky if someone
manages to overwrite it. Maybe just statically switching.
_ Compiling the backends separately is a bit excessive, as they are not
strictly backends since they use the client functions (seeing a backends folder
I thought the pgsql plugin would talk the pgsql protocol ^^). To me the
singlelib should be the only possibility (allowing the static switching from
above).
_ There is no possibility to send the values separately from the statement (as
with PQexecParams). I would argue it to be the only way to send values (and no
explicit escaping).
_ Sending values other than strings (just int, double and struct tm), and
getting them also, like in dbi_result_get_fields from libdbi (but with less
format bloat ^^).
_ Why having two functions (init+bind) to connect? With pgsql it requires to
store host and port strings. With a unique function the options could still be
specified : if before connection, they will try to be matched when connecting,
if after connection, the backend will try to update them. If these two
functions are here to speed pooling, I think this feature will be rarely used
in practice.
_ Casting out the majority of preprocessing instructions (see also debugging
below).
_ Use of NDEBUG, defined in assert.h, instead of ENABLE_DEBUGLOG, while logging
in stderr and redirecting it to a file:
#ifndef NDEBUG
#define debug_printf(...) fprintf(stderr, __VA_ARGS__)
#else
#define debug_printf(...) ((void) 0)
#endif
freopen("log.txt", "w", stderr);
_ I like the current error codes - if negative you would have to manually set
them, and to reorder if one becomes obsolete.
_ The use of void* fields is like unions, unrecommended. At the expense of a
little more memory (storing all pgconn*, MYSQL*, ... handles side by side), you
get static type checking.
_ Sometimes I see a chain of -> operators. In x86 each generates a LEA
instruction, so I would argue to minimize their use as possible.
That's all, I hope no point was unclear. BTW your code was really clean and
easy to read!
Best regards,
Thibault
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
libopendbx-devel mailing list
libopendbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
http://www.linuxnetworks.de/doc/index.php/OpenDBX
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
libopendbx-devel mailing list
libopendbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
http://www.linuxnetworks.de/doc/index.php/OpenDBX
