Tom Lane wrote:
Does anyone think this might be too chatty?
No.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Sep 1, 2008 at 12:59 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Does anyone think this might be too chatty?
No.
+1
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
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
Tom Lane wrote:
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.
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
I
On Sun, Aug 31, 2008 at 6:18 AM, Tom Lane [EMAIL PROTECTED] wrote:
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.
...
This seems like it'd be a pretty useful thing to have in long queries,
but in short
Brendan Jurd [EMAIL PROTECTED] writes:
On Sun, Aug 31, 2008 at 6:18 AM, Tom Lane [EMAIL PROTECTED] wrote:
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.
...
This seems like it'd be a pretty useful
Gregory Stark [EMAIL PROTECTED] writes:
Brendan Jurd [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] writes:
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
