Stephan Szabo <[EMAIL PROTECTED]> writes:
> It looks to me like we should be supporting any exact numeric with scale 0
> there (at least AFAICS from SQL92 and SQL03), so I don't think the current
> behavior is compliant. It doesn't look like adding a numeric overload
> of the function works, and the function also becomes ambiguous for int2
> inputs. :(
Currently (see gram.y, about line 7600) the grammar converts
SUBSTRING(foo FOR bar)
into
pg_catalog.substring(foo, 1, bar)
and then leaves the normal function-call-analysis code to make the best
of it with that. If "bar" isn't implicitly castable to integer then
you've got trouble.
I was toying with the idea of making it translate instead to
pg_catalog.substring(foo, 1, (bar)::int4)
since AFAICS there isn't any other reasonable mapping once you have
committed to having the "1" in there. This does not solve the general
problem, but it'd address the particular case anyway ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
