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
