Heikki Linnakangas writes:
> ... But pointing to ESCAPE is just weird.
I've changed these all to @2 (LIKE, ILIKE, SIMILAR TO).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
Tom Lane wrote:
> select nosuchfunction(1,2,3,avalidfunction(4));
>^
>
> select nosuchfunction(1,2,3,avalidfunction(4));
> ^
>
> Which of these is less likely to be misread about which function is
> being
Heikki Linnakangas writes:
> ... But pointing to ESCAPE is just weird.
Maybe. The implementation's-eye view of this is that the construct is
data SIMILAR-operator (pattern ESCAPE-operator escape-char)
but I agree that isn't the way a user will think of it. I could see
making the locat
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Uh, why? It looks like it's complaining about the constant 123,
>> not about the operator.
> I wrote that before I saw your post, which left me ambivalent. My
> thinking was that it seems clearest to me when it points to the token
> at which thing
Tom Lane wrote:
> Heikki Linnakangas writes:
>> BTW, the corresponding error in the "SIMILAR TO ... ESCAPE ..." syntax is:
>
>> postgres=# SELECT 'aa' SIMILAR TO 123 ESCAPE 'f';
>> ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist
>> LINE 1: SELECT 'aa' SIMILAR TO 123 ES
Heikki Linnakangas writes:
> BTW, the corresponding error in the "SIMILAR TO ... ESCAPE ..." syntax is:
> postgres=# SELECT 'aa' SIMILAR TO 123 ESCAPE 'f';
> ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist
> LINE 1: SELECT 'aa' SIMILAR TO 123 ESCAPE 'f';
>
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Heikki Linnakangas wrote:
>>> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>>>^
>
>>> LINE 1: SELECT 'aa' SIMILAR TO 123;
>>> ^
>
>>> I think the former error location is better.
>
>> So do I.
>
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Heikki Linnakangas wrote:
>>> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>>>^
>
>>> LINE 1: SELECT 'aa' SIMILAR TO 123;
>>> ^
>
>>> I think the former error location is better.
>
>> So do I.
"Kevin Grittner" writes:
> Heikki Linnakangas wrote:
>> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>>^
>> LINE 1: SELECT 'aa' SIMILAR TO 123;
>> ^
>> I think the former error location is better.
> So do I.
Uh, why? It looks like it's co
Heikki Linnakangas wrote:
> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>^
> LINE 1: SELECT 'aa' SIMILAR TO 123;
> ^
> I think the former error location is better.
So do I.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
Heikki Linnakangas writes:
> Here's an example that exercises those paths:
> postgres=# SELECT 'aa' NOT SIMILAR TO 123;
> ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist
> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>^
> HINT: No functi
Gokulakannan Somasundaram wrote:
> Hmmm no-one else feels this as a bug
>
> The logic is that a function call is made for "similar" and the position
> where SIMILAR occurs is at the third position, but it has been coded that it
> is at fifth position.
The function call is constructed for
Hmmm no-one else feels this as a bug
The logic is that a function call is made for "similar" and the position
where SIMILAR occurs is at the third position, but it has been coded that it
is at fifth position.
Thanks,
Gokul.
On Tue, Oct 27, 2009 at 6:51 AM, Gokulakannan Somasundaram <
gok
Hi,
In the gram.y, under a_expr rule
under the subrule "a_expr NOT SIMILAR TO a_expr%prec SIMILAR"
the action is as follows
{
FuncCall *n = makeNode(FuncCall);
n->funcname = SystemFuncName("similar_escape");
n->args
14 matches
Mail list logo
