On Wed, Dec 11, 2013 at 10:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
>> On Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>> Now, PG has no any tool for checking dependency between functions and other
>>> objects.
>
>> Isn't that already done for SQL function's (fmgr_sql_validator)?
>
> Pavel's point is that the only way to find out if the validator will fail
> is to run it and see if it fails; and even if it does, how much will you
> know about why?
One of the important thing at time of function creation, users are
interested in knowing is that if there are any objects (table/view/sequence ..) that are
used in function body and are missing and the reason is I think they don't want such
things to come up during execution.
Similar thing happens for prepared statements in PostgreSQL, like
at time of parse message only it checks both syntax errors and semantic check (which ensures
statement is meaningful, for ex. whether objects and columns used in the statements exist)
Like we do checks other than syntax check at time of creation of
prepared statement, same thing should be considered meaning full at time of function creation.
As you mentioned, there are checks (like dependency, mutual
recursion) which are difficult or not feasible in current design to perform, but so will be the case for
them to execute during first execution of function. So is it not better to do what is more feasible during
function creation rather than leaving most of the things at execution phase?
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com