2009/8/4 Tom Lane <tgl@sss.pgh.pa.us>:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Tom Lane wrote:
>>> Lastly, I'm not as sure as you are that the case for these is well made.
>>> In exactly what cases would client code be able to do something useful
>>> with them? Your proposal involves a pretty huge amount of work if we
>>> are to carry it out thoroughly, and I'm 100% not convinced that there's
>>> a proportional benefit.
>
>> Hmm, well, I skipped the rationale because it has been requested before.
>> For example, we need to give constraint names so that applications can
>> tell which unique key is being violated. We need table names on which
>> they are being violated. We need column names for datatype mismatches,
>> and so on. We frequently see people parsing the error message to
>> extract those, but that is known to be fragile, cumbersome and error
>> prone.
>
> Frankly, I don't believe it. I've seen possibly one or two requests
> for such things. That's not enough interest to justify the kind of
> work and code-size investment you're talking about.
>
> If there are situations where this info is missing from the
> human-readable message, then sure, let's look into fixing that.
> But the use-case for automatic interpretation of the message
> is just a whole lot smaller than would justify the work.
> To take just one point, I rather doubt that SQLSTATE codes are really
> sufficiently fine-grained to let applications automatically determine
> what to do without looking at the message text.
I can see sense of special err attrib for constraints, table and
columns. This should to help with error procession on application
level. This is language independent and +/- more stable than error
messages.
regards
Pavel Stehule
>
> 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
>
