
> 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.

Sounds good to me. 

When those are really truncated ESQL/C needs to set a warning in sqlca.sqlwarn
though, thus I think the second signature should also have an output flag to tell 
whether truncation actually occurred.
Maybe this should be kept for a protocol change though, since I would not think
a NOTICE would be suitable here. 

Andreas

Tue, 17 Sep 2002 09:33:34 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Proposal for resolving casting issues 
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> When those are really truncated ESQL/C needs to set a warning in sqlca.sqlwarn
> though, thus I think the second signature should also have an output flag to tell 
> whether truncation actually occurred.
> Maybe this should be kept for a protocol change though, since I would not think
> a NOTICE would be suitable here. 

Again, I don't want to invent output arguments for functions today ;-).

I agree that a NOTICE would be overkill, and that we need a protocol
change to implement completion conditions (sqlca.sqlwarn) properly.
When that happens, I think the explicit-cast paths in the coercion
routines can easily call the "set a completion condition" routine for
themselves; I see no reason to pass back the condition one level
before doing so.

			regards, tom lane

Tue, 17 Sep 2002 09:21:00 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal for resolving casting issues 