On Thu, Aug 28, 2008 at 9:09 PM, Christophe <xof@xxxxxxxxxxxx> wrote:
Actually because reading the string from a table prevents the function from being immutable (it could be stable), it could not be used in an index. However, you're right though that where the string came from is really not important. My point is that nobody would have expectations of execute tracking dependencies of the sql it executes for the same reason nobody has expectations that sql that lives in application code will have it's dependencies tracked by PG...
Of course, the string could come from anywhere. There's no inherent reason that I can think of (except good taste) that you could not write a function that retrieved a string out of a field in a table, executed it, and returned that as a value for use in an index. The client didn't send the string along, but it still creates dependencies.
On Aug 28, 2008, at 7:04 PM, Matthew Dennis wrote:
The plpgsql execute statement, as I understand it, means "take this string and execute like a client sent it to you".
Anyway, as was correctly pointed out, tracking dependencies in PL/pgSQL is bad enough, but PL/Java, PL/Perl...
Actually because reading the string from a table prevents the function from being immutable (it could be stable), it could not be used in an index. However, you're right though that where the string came from is really not important. My point is that nobody would have expectations of execute tracking dependencies of the sql it executes for the same reason nobody has expectations that sql that lives in application code will have it's dependencies tracked by PG...
