On 1/30/16, Pavel Stehule <pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers