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: (view raw, whole thread or download thread mbox)
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?


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-2017 The PostgreSQL Global Development Group