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
The following SE-PostgreSQL patches are updated.
It contains rebasing to the lastest CVS and fixes at invocation of trusted
procedures via operators. Rest of parts are unchanged.
[1/4]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r980.patch
[2/4]
http://sepgsql.googlecod
"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
My apologies if this is a duplicate. I think the attachment size was too
big.
Reference: Bruce Momjian writes: ->
http://archives.postgresql.org/pgsql-committers/2007-09/msg00402.php
Other references: Boyer Moore?? ->
http://www.cs.utexas.edu/users/moore/best-ideas/string-searching/fs
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
"Stephen R. van den Berg" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ({ Node *__result__; \
> Please avoid identifiers starting with __ .
Yeah, I had misremembered which way that rule went. It's "_result"
as committed.
regards, tom lane
--
Sent via pgsql-hack
Tom Lane wrote:
>Accordingly, I'm going to go ahead with this:
>#ifdef __GNUC__
>/* With GCC, we can use a compound statement within an expression */
>#define newNode(size, tag) \
>({ Node *__result__; \
Please avoid identifiers starting with __ .
ANSI reserves those for the implementation
10 matches
Mail list logo
