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

From Tom Lane
Subject Re: Attaching error cursor position to invalid constant values
Date
Msg-id 29336.1220159585@sss.pgh.pa.us
Whole thread Raw
In response to Re: Attaching error cursor position to invalid constant values  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Attaching error cursor position to invalid constant values  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> "Brendan Jurd" <direvus@gmail.com> writes:
>> What about implementing some kind of cutoff point for query length.

> Perhaps there could be a psql option to control whether to show the error
> position and perhaps that setting could be based on the length of the query or
> how many lines are in it but that seems unnecessarily baroque.

Yeah, if we were to do something like that it should clearly be a
client-side decision.

> It doesn't seem outrageously chatty to me. Better to err on the side of being
> too helpful to the user than not helpful enough.

Currently, for the things we show an error cursor for, there's no lower
limit on query length, eg

regression=# select nosuchcol from int4_tbl;
ERROR:  column "nosuchcol" does not exist
LINE 1: select nosuchcol from int4_tbl;              ^
regression=# 

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Next
From: Gregory Stark
Date:
Subject: Re: Attaching error cursor position to invalid constant values