Franck Verrot <fra...@verrot.fr> writes:
> As far as I know, there is currently no way to find which column is triggering
> an error on an INSERT or ALTER COLUMN statement. Example:
Indeed ...
> Given my very restricted knowledge of PG's codebase I am not sure whether my
> modifications are legitimate or not, so please don't hesitate to comment on
> it and pointing where things are subpar to PG's codebase. In any case, it's
> to be considered as WIP for the moment.
I think the way you're going at this is fundamentally wrong. It amounts
to an (undocumented) change to the API for datatype input functions, and
the only way it can work is to change *every datatype's* input function
to know about it. That's not practical. More, it doesn't cover errors
that are thrown from someplace other than a datatype input function.
Evaluation errors in domain check constraint expressions are an example
that would be very hard to manage this way. And the approach definitely
doesn't scale nicely when you start thinking about other contexts wherein
a datatype input operation or coercion might fail.
What seems more likely to lead to a usable patch is to arrange for the
extra information you want to be emitted as error "context", via an error
context callback that gets installed at the right times. We already have
that set up for datatype-specific errors detected by COPY IN, for example.
If you feed garbage data to COPY you get something like
ERROR: invalid input syntax for integer: "foo"
CONTEXT: COPY int8_tbl, line 2, column q2: "foo"
with no need for int8in to be directly aware of the context. You should
try adapting that methodology for the cases you're worried about.
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
