Re: Queries using rules show no rows modified?

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> You are confusing client behavior (by which I meant application)
> with library behavior. In libpq terms, an application that's sent
> an INSERT command might expect to be able to retrieve an OID with
> PQoidValue(). Whether the library avoids core-dumping doesn't mean
> that the calling app will behave sanely.

No, Tom, I'm not confusing them. I'm in no way concerned with
PQcmdTuple coredumping because the published interface specifies that
it can return a null string if it finds it necessary, which implies
that somewhere down there it's doing some decent error handling to
figure out if it's gotten something back it can make sense of and
acting appropriately.

You brought up core dumps. My concern has been exclusively with the
potential change in behavior this can cause in applications.

So I've been doing is going and downloading the source to, and looking
at the behavior of, some of the libraries that some---probably many,
maybe even most---clients are using, those for perl and python and
php, and I am finding that most of them do not even expose the
information whose (mis-)interpretation concerns you.

So, for those interfaces, at least, there was no problem to be fixed
in the first place.

Still, you don't have to have something actively breaking to warrant
fixing a bug, so there's no reason to have not made the change that
was made.

The problem is that, at the same time, I am finding that the change to
postgresql 7.2 may make application code using those interfaces begin
to operate in new and different ways because, although they aren't
paying attention to the string, which you are concerned with, they
*are* paying attention to the numbers.

Many of those interfaces, where they used to return 1 or 10 or 5000 or
6432456, will now be returning 0, which thanks to the great C
tradition, is often interpreted to mean "false", which may lead an
application to question why "nothing happened." As mine did.

And this isn't necessarily application programmers making bad choices;
the Perl interface, at least, documents the fact that it returns the
number of rows affected or -1 if that is unknowable---but the change
in behavior leads the perl interface to think it knows, when in fact
it doesn't.

If I knew java better, I'd check the JDBC driver. I mean, imagine:
Perl, python, php and java, all with undocumented unpredictable
behavior in the presence of 'update do instead' rules. Break all four
and you've just created a potential problem for everyone who does web
development.

That, I think, is one of the more egregious changes in behavior I've
seen in the few years I've been following PostgreSQL, and yet not only
is there any documentation, I feel like I'm having to fight to even
get it acknowledge that it is the bigger problem than the blasted
strings not matching because it affects a heck of a lot more stuff in
a much more direct manner.

Still, handle this however you want. I'll go fix the Perl driver to
pretend PQcmdTuples doesn't exist, since it can't be trusted to
deliver reliable information, and just have it return -1, and *my*
apps will be OK. Maybe some months down the road when 7.3 finally
straggles into view there will be a solution. Hopefully no one will
have been burned.

Anyway, I'm done beating this dead horse, since the display is
obviously bothering people.

Mike.