"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). The reason the optimizer is
presently staying away from this sort of thing is that it isn't
sure whether it's safe to reduce, say, "int2var + 32767::int4"
to "int2var + 32767::int2" (maybe oops, maybe OK, but for sure
the absence of elog during the constant-reduction doesn't tell
you enough). AFAICS we need a whole lot of datatype-and-operator-
specific semantic knowledge to be able to do that kind of reduction
safely.
As things currently stand, you could catch an elog() escape and not
propagate the error *if* you had carefully analyzed all the possible
errors that would be generated by the piece of code you intend to call
and figured out that they were all "safe". That strikes me as both a
ticklish analysis to begin with and horribly subject to future breakage,
for any but the most trivial of called routines. int2eq is perhaps
simple enough to be analyzed completely ;-) ... but the approach
doesn't scale.
regards, tom lane