On Thu, Aug 28, 2008 at 9:01 PM, Christophe <xof(at)thebuild(dot)com> wrote:
> 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.
> Oh, ouch, right.
> 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.
In response to
pgsql-general by date
|Next:||From: Matthew Dennis||Date: 2008-08-29 02:27:17|
|Subject: Re: indexes on functions and create or replace function|
|Previous:||From: Greg Smith||Date: 2008-08-29 02:13:35|
|Subject: Re: WAL archiving to network drive |