Skip site navigation (1) Skip section navigation (2)

Re: ToDo: plpgsql plugin for query and expression verification

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ToDo: plpgsql plugin for query and expression verification
Date: 2010-02-16 15:55:38
Message-ID: e08cc0401002160755i219127berbdd5cb66033a1d34@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2010/2/16 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 2010/2/16 Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>:
>> 2010/2/16 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>>> I think, so these problem have to be identified in compile stage - but
>>> it can be too strict for all (and can slow down production) - it is
>>> reason for plugin.
>>>
>>> What do you think about this idea?
>>
>> How do you identify them? Running function body cannot be applied if
>> the function is volatile. Also, I don't see how do you choose function
>> argument values even in immutable cases.
>
> It is issue only for dynamic sql and polymorphic functions. But for
> all others we can do full check in validation stage. I thinking about
> similar tool to lint - just for plpgsql function. It cannot detect all
> bugs, but it can diagnose 99% of possible issues.
>
> I don't would to execute function - it is useless because you need
> good UI for execution all path. My idea is different. gram.y has
> check_sql_expr rutine. This is used for parser checking every static
> SQL fragment in plpgsql function. With some hook we can do full plan
> generation instead.

Hmm, type mismatching can be checked by your suggestion, but that's
it. The true answer to your original post might be "write unit test",
isn't it?

Regards,


-- 
Hitoshi Harada

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-02-16 16:00:37
Subject: Re: bug? autovacuum is not launched even if autovacuum_freeze_max_age is reached
Previous:From: Marc G. FournierDate: 2010-02-16 15:55:12
Subject: Re: OpenVMS?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group