Gregory Stark <[EMAIL PROTECTED]> writes:
> Hm, I suppose this "kluge" in gram.y for "substr_list" isn't necessary any
> more?
It's still necessary, because if you write
select substring('1234' for '3');
you should get "123", but what you will get without the cast is "3"
because the preferred match will be to substring(text,text).
Also, the original example was from someone who had tried to use a
bigint column for the second parameter. That case would start to draw
ERROR: function pg_catalog.substring(unknown, bigint) does not exist
which doesn't seem helpful, when we know perfectly well that the only
functions this syntax should match take int4.
Probably the comment should be fixed.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
