Re: Attaching error cursor position to invalid constant values

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> and I don't recall having heard any complaints about that. I was just a
> bit shell-shocked by the number of regression test diffs my patch
> generated. But on looking closer, the reason is the intentional testing
> of bad values in a lot of the datatype-specific tests. So that's
> probably not a good indicator of how chatty it'll seem to regular users.

The only logical argument I see here for why this case is any different is
that since the constant is present in the original query and it's repeated in
the error the user has enough information to immediately identify the source
of the error. That's not true for other types of errors where the site of the
error isn't obvious from the error message.

But even for constants it's not entirely true either. You could have something
like:

select 'foo'+0, 'foo'+0.0;

and when you get the error the you would have to deduce which constant is in
error based on the type it describes. That could be quite a bit more complex
than this example.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!