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
functioncalled 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
codethat 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 <jm.poure@freesurf.fr>
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
