Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group