Re: Queries using rules show no rows modified? - Mailing list pgsql-hackers

Tom Lane <tgl@sss.pgh.pa.us> writes:
> Last I checked, I objected to your solution and you objected to mine
> ... so I think it's on hold until we get some more votes.

Well, If I'm reading this code from DBD::Pg's dbdimp.c correctly, I
think that the perl module, at least, feels that the number is much
more important than the actual command that is returned:
   if (PGRES_TUPLES_OK == status) {       [...]   } else if (PGRES_COMMAND_OK == status) {       /* non-select
statement*/       if (! strncmp(cmdStatus, "DELETE", 6) || ! strncmp(cmdStatus, "INSERT", 6) || ! strncmp(cmdStatus,
"UPDATE",6)) {           ret = atoi(cmdTuples);       } else {           ret = -1;       }
 

It appears that while the implementation does look to make sure the
return string is recognizable, it doesn't care too much beyond that
which one it is---not suprising as that string is, as far as the DBI
interface is concerned, just "extra information" that has no defined
interface to get back out to the user.  More important, at least from
the standpoint of a user of the module seems to be that the cmdTuples
(gotten from PQcmdTuples) represents number affected so it can be
returned.

In fact, now that I look at it, this change has in fact broken the
DBD::Pg interface with respect to the DBI when used in the presence of
rules, because the DBI spec states that it will either return the
number of tuples affected or -1 if that is unknown, rather than 0,
which breaks as a result of this change.

I guess there's an argument to be made as to whether PostgreSQL
provides any guarantees about this number being correct or even valid,
but the fact that the library interface makes it available, and I see
nothing in the documentation of the function that suggests that that
number is unreliable suggests that it is not an error to depend on it.

So, If I understood the proposals correctly, I think that means that
this implementation argues for, or at least would work well with,
Hiroshi's solution, since yours, Tom, would return a false zero in
certain (perhaps rare) situations, arguably loosing information that
the perl module, at least, could use, and the library purports to make
available, in order to preserve information it does not.

I guess there is one other possibility, though I don't know how
radical it would be in either implementation or effects: return the
empty string from PQcmdTuples in this situation.  It serves as
something of an acknowledgement that what went on was not necessarily
fish or fowl, while still being, from my reading of the docs, a valid
return.  The perl module certainly regards it as one, albeit one that
transmits precious little information.  Well-written interfaces should
already be able to cope with it, given that it is documented as a
possiblity in the docs, right?

Mike.