Re: char/varchar truncation

On Sat, 3 Aug 2002, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> > I wonder if we actually did the right thing with this.
> > ...
> > Wouldn't that mean the operation is supposed to succeed with
> > diagnostic information since it's a completion condition not
> > an exception condition?
>
> Hm. You are right: an explicit cast to varchar(n) has different
> behavior according to the spec than a store assignment (ie,
> implicit coercion) to varchar. The implicit coercion should fail.
>
> AFAIR our cast mechanisms aren't prepared to use two different
> routines for these two cases. Looks like we have some work to do.

As a note, looking at the spec again, cast(12 as char(1)) should fail
while cast('12' as char(1)) should succeed with notice, and both 12 and
'12' should fail when being put into a column of char(1). So, it's
dependant on both whether cast() was used and on the source type.

I went poking around a little bit looking at the stuff in
parse_coerce.c and related, but haven't had time to look
too deeply at its callers.

Right now there are two paths that seem to be be able to cause the length
errors. One is in coerce_type_typmod, the other is in the type's input
function (for conversion from unknown). For the call to the input function
from coerce_type it looks like we wouldn't need to pass a non -1 typmod
since the coerce_type_typmod that really should follow (since without it
you'd get broken behavior in the non-unknown case) would catch it. That'd
allow us to fix the behavior through only one path. I assume that the
input function would continue working in the same fashion for non -1
typmods. This also gets us around needing to change the input function's
arguments.

I believe that we'd want to store typmod conversion data in the pg_cast
row for the conversion we're doing. coerce_type_typmod could then lookup
the function that way (rather than from the typename and oid). I'm a
little worried about the fact that we would be doing more searches
on pg_cast. Haven't thought of a better way (admittedly having not
searched too hard yet either). This seems preferable to doing some kind
of hardcoded check on the source type since it allows user conversions
to work either way. One side effect of this is that we could end up with
more rows in pg_cast since int->char(n) is no longer quite like int->text
and we'd want to be able to specify what happens for char(n)->char(m).

Does any of that seem reasonable as a starting point for exploration?