I've made a single general purpose routine that send the query to the database and returns the most useful thing the database throws back at it, being a record-set (with 0..n elements), the autoinsertID (mysql only) or the amount of rows affected.
The function performs three very different tasks. You shouldn't have to find and mentally parse the SQL query to find out what the function returns. Contrary to what you said, that makes the interface more complex, not simpler.
and suits 100% of the use cases I have met last year.
As indicated by your reply, it's complexity being discussed, not functionality. Highly polymorphic functions are more complex and less elegant than something more straightforward.
The query entry interface of many database management systems, like phpmyadmin or PGadmin3, don't have separate input fields for separate query types either.
They provide a UI, not an API. Which are you building?
In reply to Re^3: How to detect postgresql RETURNING usage
by ikegami
in thread How to detect postgresql RETURNING usage
by Roland684
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |