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-hacke
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
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 datatype-s
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
"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 pr
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 s
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
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=# selec
