From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Harald Fuchs <hf0923x(at)protecting(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 8.1 substring bug? |
Date: | 2005-11-11 15:47:12 |
Message-ID: | 20051111073935.B1473@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 11 Nov 2005, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > It's even sillier than that:
>
> > test=# SELECT substring ('1234567890' FOR 4::bigint);
> > substring
> > -----------
> >
> > (1 row)
>
> > test=# SELECT substring ('1234567890' FOR 4::int);
> > substring
> > -----------
> > 1234
> > (1 row)
>
> 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. :(
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-11-11 16:02:21 | Re: 8.1 substring bug? |
Previous Message | Andrew Dunstan | 2005-11-11 15:36:21 | Re: generic builtin functions |