Alvaro Herrera <alvhe...@commandprompt.com> writes: > First we need several new error message fields: table name, function > name, constraint name, and so on.
It would also help to have clear definitions of what these *mean*, which is entirely unclear from your comments --- in particular, the reference to errcontext callbacks confuses the heck out of me. I would have thought that these would be used for the referenced object name in cases like "table not found", and surely using an errcontext callback for that would be the hardest possible way to implement it. > ... would be to give each new field its own start letter (see > http://www.postgresql.org/docs/8.4/static/protocol-error-fields.html); > say "T" for table, "f" for function (F is taken), "c" for constraint (C > is taken), and so on. Another possibility would be to use a single > letter, say N, and add a subtype to it; so table name would be "NT" > followed by the table name, NF for functions, etc. Without a pretty concrete list of what the additions are going to be, it's difficult to make any reasoned choices there. 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. 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
