Tom Lane <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
