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

From Tom Lane
Subject Attaching error cursor position to invalid constant values
Date
Msg-id 11413.1220127537@sss.pgh.pa.us
Whole thread Raw
Responses Re: Attaching error cursor position to invalid constant values  ("Stephen R. van den Berg" <srb@cuci.nl>)
Re: Attaching error cursor position to invalid constant values  ("Brendan Jurd" <direvus@gmail.com>)
Re: Attaching error cursor position to invalid constant values  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
I'm fooling around with getting the parser to report an error cursor
location if input conversion fails for a constant in a SQL command.
For instance:

regression=# select 42 = 'foo';
ERROR:  invalid input syntax for integer: "foo"
LINE 1: select 42 = 'foo';                   ^
regression=# select '2000-jax-01'::date;
ERROR:  invalid input syntax for type date: "2000-jax-01"
LINE 1: select '2000-jax-01'::date;              ^
regression=# 

This seems like it'd be a pretty useful thing to have in long queries,
but in short queries it looks a bit like overkill.  And it affects
the expected output of a whole lot of the regression tests.

Does anyone think this might be "too chatty"?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Is it really such a good thing for newNode() to be a macro?
Next
From: "David Rowley"
Date:
Subject: TODO item: Implement Boyer-Moore searching (First time hacker)