Peter Geoghegan <peter.geoghega...@gmail.com> writes: > On 27 January 2013 18:57, Tom Lane <t...@sss.pgh.pa.us> wrote: >> However, this patch is not that, and mere documentation isn't going to buy a >> thing here IMO. Especially not user-facing documentation, as opposed >> to something that might be in a developers' face when he's >> copying-and-pasting code somewhere. This patch didn't even touch the >> one place in the documentation that might be somewhat useful from a >> developer's standpoint, which is 49.2. Reporting Errors Within the >> Server.
> Well, an entry should probably be added to 49.2 too, then. Why should > documentation (of whatever kind deemed appropriate) not buy a thing? > Don't we want to prevent the kind of problems that I describe above? > How are people supposed to know about something that isn't written > down anywhere? Surely documentation is better than nothing? I don't think I said or implied that we should not have any documentation about this. What I'm trying to say is that I find this approach to documentation unhelpful, both to users and developers. It's based on the notion that there's a rigorous connection between particular SQLSTATEs and the auxiliary fields that should be provided; an assumption already proven false within the very tiny set of SQLSTATEs dealt with in this first patch. That's a connection that we probably could have made valid if we'd been assigning SQLSTATEs with that idea in mind from the beginning, but we didn't and now it's too late. Future development will almost surely expose even more inconsistencies, not be able to get rid of them. I think we'd be better off providing docs that say "this is what this auxiliary field means, if it's provided" and then encourage developers to provide it wherever that meaning applies. We can at the same time note something like "As of Postgres 9.3, only errors in Class 23 provide this information", so that users (a) don't have unrealistic expectations about what's provided, and (b) don't get the idea that the current set of auxiliary fields is fixed. But a SQLSTATE-by-SQLSTATE listing doesn't seem to me to be very helpful. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers