ILIKE will not work correctly in *many* situations. Consider the following functions:
my_sum(int4, int4) RETURNS int4 my_sum(int8, int8) RETURNS int8 In a function, a line of code reads: $var = my_sum($1, $2); How do we know which function this is without parsing the code to figure out what $1 & $2 are? This is complicated more when a pl may contain code that matches the ILIKE, for example if there were a builtin python function called my_sum. The pl/python handler could deal with that, but a simple ILIKE would give a false positive. ILIKE will also fail with: my_sum(int4, int4) "My_Sum"(int4, int4) My_Sum(int4, int4) all of which are valid, but not necessarily equivalent. If you can come up with a solution that overcomes these and any similar problems, great, but I do not want to release code that cannot be relied upon without having lot's of caveats about how you can use it. Regards, Dave. _____________Original message ____________ Subject: Re: [pgadmin-hackers] Feature requests after crash Sender: Jean-Michel POURE <[EMAIL PROTECTED]> Date: Fri, 22 Feb 2002 13:11:47 +0000 Le Jeudi 21 F�vrier 2002 23:39, Dave Page a �crit : > Without these parsers, we will not be able to track dependencies within > functions or views. Why do we need parsers? pgAdmin I had very simple queries to track dependencies (ILIKE '%function_foo%' clause). This suffice to build a provides clause is each object. For example, if "function_foo" is used in "view_bar" and "function_bar": function_foo->provides="function:function_bar;view:view_bar" view_bar->requires="function:function_foo"; function_bar->requires="function:function_foo"; If you prefer, provides = child, requires = father. I agree this is not as powerfull as a recursive dependency table, but this suffice to offer 99% security to users. The purpose is not to track n-levels of dependecies but just visualize 1 level for security reasons. So why not implement it in pgSchema? Cheers, Jean-Michel
