Re: Proposal for resolving casting issues

I said:
> Also, I think we should allow cast functions to take an optional boolean
> second argument "isExplicit", so that explicit casts can be distinguished
> from implicit at runtime. We'll use this to get spec-compliant semantics
> for char/varchar truncation (there shouldn't be an error if you explicitly
> cast to a shorter length).

After looking closely at SQL92 sections 6.10 (cast specification) and
9.2 (store assignment), it seems that the only places where the spec
demands different behavior for an explicit cast than for an implicit
assignment cast are for length coercions of char, varchar, bit, and
varbit types.

Accordingly, the places where we actually *need* the extra isExplicit
argument are not in the type-coercion functions per se, but in the
length-coercion functions associated with these four datatypes.

While we could still add the extra argument for the type-coercion
functions, I'm inclined not to do so; there is no need for it for spec
compliance of the standard types, and I don't think we should encourage
user-defined types to behave differently for explicit and implicit
casts.

What I will do instead is adjust parse_coerce.c so that a
length-coercion function can have either of the signatures
foo(foo,int4) returns foo
or
foo(foo,int4,bool) returns foo
and then modify the above-mentioned length coercion functions to provide
the desired behavior. This has no direct impact on pg_cast because we
do not use pg_cast for length-coercion functions.

regards, tom lane