Re: plpgsql_check_function - rebase for 9.3 - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plpgsql_check_function - rebase for 9.3
Date
Msg-id CAFj8pRAL2s2EkuaW7L-jp24Zowovr9yfm_Dmc3JBBCwouzkETw@mail.gmail.com
Whole thread
In response to Re: plpgsql_check_function - rebase for 9.3  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers



2013/12/9 Peter Eisentraut <peter_e@gmx.net>
On 12/8/13, 12:01 PM, Pavel Stehule wrote:
> But still I have no idea, how to push check without possible slowdown
> execution with code duplication

Create a GUC parameter plpgsql.slow_checks or whatever (perhaps more
specific), which people can turn on when they run their test suites.

This doesn't really have to be all that much different from what we are
currently doing in C with scan-build and address sanitizer, for example.


A main issue is placing these tests on critical path.

You have to check it in every expression, in every internal switch

There are two main purposes

a) ensure a expression/query is valid (not only syntax valid)
b) search all expressions/queries - visit all possible paths in code.

so you should to place new switch everywhere in plpgsql executor, where is entry to some path.

Second issue - these check decrease a readability of plpgsql statement executor handlers. This code is relative very readable now. With new switch is little bit (more) less clean.

I think so fact we use a two other large statement switch (printing, free expressions) is natural, and it hard to write it better.

Regards

Pavel

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [patch] Adding EXTRA_REGRESS_OPTS to all pg_regress invocations
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: logical changeset generation v6.7