in reply to Re: How to detect postgresql RETURNING usage
in thread How to detect postgresql RETURNING usage

I could build separate subroutines for every type of query/return value possible, and although probably the most correct thing to do, this also makes the most complex interface.

E.G. The query entry interface of many database management systems, like phpmyadmin or PGadmin3, don't have separate input fields for separate query types either.

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.

And although I know this is not the most elegant thing, it is very, very simple to use and suits 100% of the use cases I have met last year.

Anyway, you were right: I have used the Active attribute to fix my issue (for now), rather than take a different approach altogether. I thank you for mentioning it.

  • Comment on Re^2: How to detect postgresql RETURNING usage

Replies are listed 'Best First'.
Re^3: How to detect postgresql RETURNING usage
by ikegami (Patriarch) on Sep 07, 2010 at 16:29 UTC

    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?