Robert Haas <robertmhaas@gmail.com> writes:
> I suppose we could change the function to return 00000 always when the
> operation is not an error or warning report, rather than NULL, but
> certainly we wouldn't want to include those bytes in *every* success
> message, so they'd have to be something that the libpq inferred. And
> I'm not clear why that behavior would be any more useful than what we
> have now; indeed, it seems like it would needlessly break backward
> compatibility.
Um. You're missing the point here. This isn't a message from the
backend, it's a complaint generated internally by libpq. The real issue
here is that there are no SQLSTATEs assigned for any error/warning
conditions generated internally in libpq. Fixing this is just a Small
Matter Of Programming, but no one's yet taken an interest in doing it.
Seeing that that's been a TODO item since 7.4, I wouldn't advise holding
your breath.
As far as this particular example goes, I think it's highly debatable
whether "out of range parameter number" should be only a NOTICE, and
almost certainly wrong to say that it ought to be associated with an
00000 SQLSTATE. But figuring out what it ought to be is part of the
dogwork that nobody's done yet.
> If you're arguing that this behavior is required by
> the spec, let's have a cite. I find it a bit surprising that the spec
> would cover the behavior of individual libpq functions in this level
> of detail.
I believe the text about "always present" is cribbed from our FE/BE
protocol specification. It is true (or at least should be true) for
error and notice messages sent from the backend.
regards, tom lane
