Re: How to detect postgresql RETURNING usage

That doesn't make much sense.

If you need values back, you'll use a query that returns the values you need (i.e. with RETURNING), and you'll collect them.

my $sth = $dbh->prepare($query);
$sth->execute;
while (my $row = $sth->fetchrow_hashref) {
  ...
}
[download]

If you don't need values back, you won't use a query that returns values you need (i.e. without RETURNING), and you won't collect them.

my $sth = $dbh->prepare($query);
$sth->execute;
[download]

I don't see the ambiguity unless you're writing yet another bad DBI wrapper. I hate to mention this since I fear it will get misused, but I think you can check for the presence of data by checking if the statement handle is Active.

Comment on Re: How to detect postgresql RETURNING usage Select or Download Code

Replies are listed 'Best First'.
Re^2: How to detect postgresql RETURNING usage by Roland684 (Novice) on Sep 07, 2010 at 11:59 UTC
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.	[reply]
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?	[reply]