From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | Dave Blasby <dblasby(at)refractions(dot)net>, thomas pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BUG: text(varchar) truncates at 31 bytes |
Date: | 2001-10-03 22:10:00 |
Message-ID: | 14613.1002147000@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> Looking at the explain verbose output, it looks like it may be doing a
> conversion to name because it looks like there isn't a text(varchar),
> but there's a text(name) and a name(varchar). My guess is there's no
> text(varchar) because they're considered binary compatible.
Since the truncation is to 31 characters, it seems clear that a
conversion to "name" happened.
I think the reason for this behavior is that the possibility of a
"freebie" binary-compatible conversion is not considered until all else
fails (see parse_func.c: it's only considered after func_get_detail
fails). Unfortunately func_get_detail is willing to consider all sorts
of implicit conversions, so these secondary possibilities end up being
the chosen alternative.
Perhaps it'd be a better idea for the option of a freebie conversion
to be checked earlier, say immediately after we discover there is no
exact match for the function name and input type. Thomas, what do you
think?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-10-03 22:27:47 | Re: Unicode combining characters |
Previous Message | Thomas Lockhart | 2001-10-03 22:05:07 | Re: CEST timezone |