Re: 8.1 substring bug?
От | Martijn van Oosterhout |
---|---|
Тема | Re: 8.1 substring bug? |
Дата | |
Msg-id | 20051111160221.GK13177@svana.org обсуждение исходный текст |
Ответ на | Re: 8.1 substring bug? (Stephan Szabo <sszabo@megazone.bigpanda.com>) |
Ответы |
Re: 8.1 substring bug?
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: