2009/8/4 Tom Lane <t...@sss.pgh.pa.us>: > Alvaro Herrera <alvhe...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
