Re: PATCH: CITEXT 2.0 v3
От | David E. Wheeler |
---|---|
Тема | Re: PATCH: CITEXT 2.0 v3 |
Дата | |
Msg-id | 8FFA9421-A61D-48F1-A4CC-70C43425F8F6@kineticode.com обсуждение исходный текст |
Ответ на | Re: PATCH: CITEXT 2.0 v3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Jul 13, 2008, at 10:16, Tom Lane wrote: > Hmm. I think what that actually means is that the cast from citext to > bpchar should be AS ASSIGNMENT rather than IMPLICIT. What is > happening > is that the system can't figure out whether to use length(text) or > length(bpchar) when presented with a citext argument. I had been > thinking yesterday that it would automatically prefer length(text) > because text is a "preferred type", but after tracing through it I see > that that doesn't happen because citext is not thought to be of the > string category. (We really need a way to let user-defined types > specify their category...) That'd be nice. > The fact that you need all these piggyback functions is a red flag > because what it implies is that citext will not work nicely for any > situation where both text and bpchar functions have been provided > --- and that includes user-added functions, so it's hopeless to think > that you can get to a solution this way. Downgrading the cast seems > like the right thing to me. Yes, that works for me. I've downgraded it and can now remove the size functions and all the tests still pass. > The implicit cast to varchar is a bit worrisome because it creates the > same issue if someone has provided both varchar and text versions of a > function. However, that seems a bit pointless given the lack of > semantic difference, and I suspect that a lot of user-written > functions > come only in varchar variants --- so on balance my recommendation is > to > keep that one as implicit. Yes, I agree. Thanks for tracing this out, Tom, it never would have ocurred to me -- and now I know more than I did before! Best, David
В списке pgsql-hackers по дате отправления: