Re: Attaching error cursor position to invalid constant values - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Attaching error cursor position to invalid constant values
Date
Msg-id 87vdxh4uv4.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Attaching error cursor position to invalid constant values  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Attaching error cursor position to invalid constant values
Next
From: Dean Rasheed
Date:
Subject: Re: Auto-explain patch