On Wed, Jan 22, 2020 at 8:48 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > I wonder if we shouldn't be using errtablecol() here instead of (in > > addition to?) patching the errmsg() to include the table name. > > > Discussion: If we really like having the table names in errtable(), then > > we should have psql display it by default, and other tools will follow > > suit; in that case we should remove the table name from error messages, > > or at least not add it to even more messages. > > > If we instead think that errtable() is there just for programmatically > > knowing the affected table, then we should add the table name to all > > errmsg() where relevant, as in the patch under discussion. > > > What do others think? > > I believe that the intended use of errtable() and friends is so that > applications don't have to parse those names out of a human-friendly > message. We should add calls to them in cases where (a) an application > can tell from the SQLSTATE that some particular table is involved > and (b) it's likely that the app would wish to know which table that is. > I don't feel a need to sprinkle every single ereport() in the backend > with errtable(), just ones where there's a plausible use-case for the > extra cycles that will be spent. > > On the other side of the coin, whether we use errtable() is not directly > a factor in deciding what the human-friendly messages should say. > I do find it hard to envision a case where we'd want to use errtable() > and *not* put the table name in the error message, just because if > applications need to know something then humans probably do too. >
makes sense. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
