The docs have said this for 8 years:
| "As of PostgreSQL 9.3, complete coverage exists only for errors in SQLSTATE
class 23 (integrity constraint violation), but this is likely to be expanded in
future."
Is there any appetite for a patch like this one to improve that ?
One might argue that COLUMN NAME should not be used for a column which doesn't
actually exist...
However, we would make use of this, instead of using an regexp on the error
message.
If there's interest, I'd also start by patching these:
src/backend/catalog/catalog.c
src/backend/catalog/heap.c
src/backend/catalog/index.c
src/backend/catalog/objectaddress.c
src/backend/commands/copyfrom.c
src/backend/commands/copyfromparse.c
src/backend/commands/copyto.c
src/backend/commands/indexcmds.c
src/backend/commands/statscmds.c
src/backend/commands/tablecmds.c
src/backend/commands/typecmds.c
src/backend/commands/view.c
src/backend/executor/execMain.c
postgres=# \set VERBOSITY verbose
postgres=# SELECT a ;
ERROR: 42703: column "a" does not exist
LINE 1: SELECT a ;
^
COLUMN NAME: a
LOCATION: errorMissingColumn, parse_relation.c:3589
---
src/backend/parser/parse_relation.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/backend/parser/parse_relation.c
b/src/backend/parser/parse_relation.c
index c5c3f26ecf..09e0016129 100644
--- a/src/backend/parser/parse_relation.c
+++ b/src/backend/parser/parse_relation.c
@@ -3596,6 +3596,8 @@ errorMissingColumn(ParseState *pstate,
state->rfirst->eref->aliasname, closestfirst) :
errhint("There is a column named \"%s\" in
table \"%s\", but it cannot be referenced from this part of the query.",
colname,
state->rfirst->eref->aliasname) : 0,
+ relname ?
err_generic_string(PG_DIAG_TABLE_NAME, relname) : 0,
+ colname ?
err_generic_string(PG_DIAG_COLUMN_NAME, colname) : 0,
parser_errposition(pstate, location)));
}
else
--
2.17.0
