I dislike it. a too early check means a issues with temporary tables and mainy new dependency between functions in complex projects. It is some what we don't want. Dne 12. 12. 2013 5:30 "Amit Kapila" <amit.kapil...@gmail.com> napsal(a):
> 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 >
