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
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 |