On 1/30/16, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> P.S.: Have you thought to wrap the call "numeric_in" by a
>> PG_TRY/PG_CATCH instead of checking for correctness by yourself?
>
> I though about it, but it is not possible. Every PG_TRY/CATCH must be
> finished by RETHROW.
No, src/include/utils/elog.h tells different (emphasizes are mine):
"The error recovery code can _optionally_ do PG_RE_THROW() to
propagate the _same_ error outwards."
So you can use it without rethrowing.
> Only when you will open subtransaction and you are playing with resource manager, you can do it.
Really? I did not find it around the "#define PG_TRY()" definition in
"src/include/utils/elog.h".
I guess it is important to use a subtransaction if you want to catch
an exception and go further. In case of calling "numeric_in" from the
"pg_size_bytes" there is no reason to use a subtransaction that may
close any open relation etc., because a new ereport with different
message is emitted, which fails the current transaction anyway.
PG_TRY is only calls sigsetjmp and sets PG_exception_stack. If no
exception is emitted, penalty is the only sigsetjmp call (but I don't
know how heavy it is), if an exception is emitted, there is no matter
how long it handles.
> It is pretty expensive.
Ok. Performance makes sense.
> You can see in our code lot of situation when some function returns true,
> false, "error message" instead raising a exception.
I know. It is a common style in C programs.
> I would not to refactor numeric_in function in this style.
No doubt. It is not necessary.
> This function is in critical path of COPY
> FROM, and any more calls can decrease performance. And then I have to do
> these checks before calling.
>
> Regards
> Pavel
--
Best regards,
Vitaly Burovoy
