On Fri, Nov 11, 2005 at 07:47:12AM -0800, Stephan Szabo wrote:
>
> On Fri, 11 Nov 2005, Tom Lane wrote:
> > This has been complained of before. The problem is that there is no
> > implicit cast from bigint to int, but there is one from bigint to text,
> > so the only acceptable mapping the parser can find is to convert bigint
> > to text and apply the pattern-match version of substring(). (There are
> > some other things happening here because of the weird SQL99 syntax, but
> > that's the bottom line.)
>
> 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. :(
Other than adding explicit definitions for each and every numeric type,
is there no way to add a preference for implicit conversions?
In this particular case the syntax makes it unclear that the substring
is the problem. Perhaps here the solution would be to put a cast in the
grammer, like so:
substr_for: FOR a_expr { $$ = makeTypeCast($2,"int4"); } ;
This would make the match guarenteed since the type matches exactly, no?
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
