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

Re: ToDo: plpgsql plugin for query and expression verification

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Hitoshi Harada <umi(dot)tanuki(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 13:44:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

Pavel Stehule

> Regards,
> --
> Hitoshi Harada

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-02-16 14:04:11
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
Previous:From: Andrew DunstanDate: 2010-02-16 13:11:15
Subject: Re: OpenVMS?

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