> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> (BTW, I actually think that the current approach is more robust than
> >> exception catchers for modules that are part of the standard system;
> >> it forces on you the discipline of making sure that all recoverable
> >> resources are tracked in data structures less transient than some
> >> routine's local variables.
>
> > Hmm,for the query SELECT .. FROM .. WHERE int2key = 1;
> > we coudn't try to convert 1 -> 1::int2 because the conversion may
> > cause elog(ERROR). Isn't it too restrictive ?
>
> Well, that's not a particularly good example, because it wouldn't
> be hard at all for us to avoid reducing "int2var = 32768::int4"
> to "int2var = 32768::int2" (oops).
Hmm,am I misunderstanding ?
As for conversion functions,shouldn't they return return-code
unless they could throw "catchable" exceptions ?
If the conversion 32768::int4 -> 32768::int2 returns an error
we would be able to find that "int2var = 32768::int4" is always
false.
If I recognize correctly,"catchable" exceptions means that
we could catch them if we want(otherwise they are dealt with
a default exception handler like current elog handler). So they
would be same as elog() except the special cases we are
interested in.
Where are problems when we handle conversion functions
with return code or "catchable" exceptions ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp