Re: Attaching error cursor position to invalid constant values

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Brendan Jurd" <direvus(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Attaching error cursor position to invalid constant values
Date: 2008-08-31 05:13:05
Message-ID: 29336.1220159585@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Brendan Jurd" <direvus(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-08-31 05:27:27 Re: Attaching error cursor position to invalid constant values
Previous Message Gregory Stark 2008-08-31 04:02:04 Re: Attaching error cursor position to invalid constant values