Re: Proposal for resolving casting issues - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re: Proposal for resolving casting issues
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961E88@m0114.s-mxs.net
Whole thread Raw
In response to Proposal for resolving casting issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal for resolving casting issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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


pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: PGXLOG variable worthwhile?
Next
From: "Christopher Kings-Lynne"
Date:
Subject: Re: PGXLOG variable worthwhile?