On Wed, Dec 11, 2013 at 10:40 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: >> On Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule <pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
