Re: Feature requests after crash

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