Thanks for applying it.
> I am still unclear how I will catch such changes in the future without
> requiring users to report them.
I tried to see whether a script could find these. It walks the
commits in a range and lists the ones where an existing error starts
reporting a different SQLSTATE: a file trading one ERRCODE_* for
another, an error that used to report XX000 getting a specific code
(or the reverse), or the first use of a code that errcodes.txt already
had, which is how 086c84b23 looks. On REL_17_0..REL_18_0 it lists 25
commits, including both SQLSTATE items in the 18 notes.
On REL_18_0..REL_19_RC1, these change the SQLSTATE of an existing error
and aren't in the 19 notes:
0836683a8 PL/pgSQL: a reserved word used as a record field name
now reports 42601 (syntax_error) instead of 42703
(undefined_column)
88a658a42 amcheck: a target that isn't an index, such as a
partitioned index, now reports 42809 (wrong_object_type),
and an invalid index reports 55000
(object_not_in_prerequisite_state); both used to report
0A000 (feature_not_supported)
There are also several where an error that used to report XX000 now
has a specific code, for example 4c5291435 for the pg_restore_*_stats()
functions.
I had an AI write the script; I checked its output against the PG 17
and PG 18 release notes and verified the PG 19 items above by hand.
It can't see codes passed in variables or errors that move to another
file, so it's a list to review rather than a guarantee. Tags in commit
messages, as David suggested, would still be the better source; this
is only meant to catch what slips through. I can post the script if
it's useful.
Regards,
Kacper Kuras
