On Thu, Aug 28, 2008 at 9:01 PM, Christophe <xof@xxxxxxxxxxxx> wrote:
Yes, but in the case of pluggable languages, you still load something that constitutes the "source". In the case of PL/Java, the jar for example. Whenever it changes, the stuff that depends on it up the chain is invalidated/rechecked/whatever. When I have a table that a view references, it tracks that. When I have a function that a index references, it kind of tracks that (I can't drop it because of the dependency, but I can replace it - with no warning/error btw). It just seems a worthy goal to aspire to...
The cases about taking a string and sending it via execute don't seem to fit here for 1) cases where it is impossible to track the dependencies can be trivially constructed and 2) the very nature of the execute statement makes it obvious that it I shouldn't expect it to be tracked. Poor Analogy: In C, if foo calls bar and I remove bar I expect the compiler to tell me. If elsewhere in my code, I construct a memory address of where I believe bar should be and execute it I have no expectations for the compiler to tell me bar was removed.
Oh, ouch, right.
On Aug 28, 2008, at 6:51 PM, Alvaro Herrera wrote:
Also, you have to keep in mind that we support pluggable languages. The
function's source code is just an opaque string.
I think that this is one of those cases where it's better that we simply advertise: BE AWARE OF THIS, rather than try to provide a half-baked solution that gives the illusion of safety without the reality.
Yes, but in the case of pluggable languages, you still load something that constitutes the "source". In the case of PL/Java, the jar for example. Whenever it changes, the stuff that depends on it up the chain is invalidated/rechecked/whatever. When I have a table that a view references, it tracks that. When I have a function that a index references, it kind of tracks that (I can't drop it because of the dependency, but I can replace it - with no warning/error btw). It just seems a worthy goal to aspire to...
The cases about taking a string and sending it via execute don't seem to fit here for 1) cases where it is impossible to track the dependencies can be trivially constructed and 2) the very nature of the execute statement makes it obvious that it I shouldn't expect it to be tracked. Poor Analogy: In C, if foo calls bar and I remove bar I expect the compiler to tell me. If elsewhere in my code, I construct a memory address of where I believe bar should be and execute it I have no expectations for the compiler to tell me bar was removed.
