Matthew Dennis wrote:
Given table T(c1 int) and function F(arg int) create an index on T using
F(c1). It appears that if you execute "create or replace function F"
and provide a different implementation that the index still contains the
results from the original implementation, thus if you exe
On Thu, Aug 28, 2008 at 7:45 PM, Matthew Dennis <[EMAIL PROTECTED]> wrote:
> Another question though. Since I could potentially start transaction, drop
> indexes/checks, replace function, create indexes/checks, commit tranasaction
> could I deal with the case of the constant folding into the cach
Matthew Dennis wrote:
> 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
On Thu, Aug 28, 2008 at 8:51 PM, Alvaro Herrera
<[EMAIL PROTECTED]>wrote:
> There's no way at all in the general case (a function name could be
> passed as a parameter, for example). I think Matthew is suggesting to
> track dependencies at run time, but that seems a recipe for burnt
> fingers and
On Aug 28, 2008, at 7:22 PM, Matthew Dennis 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.
This would mean that, for example, if you changed any single function
(no matter how distan
On Thu, Aug 28, 2008 at 9:09 PM, Christophe <[EMAIL PROTECTED]> wrote:
>
> 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".
>>
>
> Of course, the string could come from a
On Thu, Aug 28, 2008 at 9:01 PM, Christophe <[EMAIL PROTECTED]> 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 t
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".
Of course, the string could come from anywhere. There's no inherent
reason that I can think of (except good taste) that yo
On Thu, Aug 28, 2008 at 8:15 PM, Christophe <[EMAIL PROTECTED]> wrote:
>
> On Aug 28, 2008, at 6:10 PM, Matthew Dennis wrote:
>
>> I'm not sure I follow. Couldn't you track which statements were prepared
>> that called a function and either reprepare (just like reindex, recheck,
>> etc) or in the
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 THI
Christophe wrote:
>
> On Aug 28, 2008, at 6:10 PM, Matthew Dennis wrote:
>> I'm not sure I follow. Couldn't you track which statements were
>> prepared that called a function and either reprepare (just like
>> reindex, recheck, etc) or in the case of dropping a function, refuse to
>> drop it
On Aug 28, 2008, at 6:10 PM, Matthew Dennis wrote:
I'm not sure I follow. Couldn't you track which statements were
prepared that called a function and either reprepare (just like
reindex, recheck, etc) or in the case of dropping a function,
refuse to drop it because something depends on it
On Thu, Aug 28, 2008 at 7:52 PM, Christophe <[EMAIL PROTECTED]> wrote:
>
> On Aug 28, 2008, at 5:49 PM, Matthew Dennis wrote:
>
>> Yes, I can see that would indeed be a problem. Are there future plans to
>> start tracking such dependencies? It seems like it would be a good idea in
>> general.
>>
On Aug 28, 2008, at 5:49 PM, Matthew Dennis wrote:
Yes, I can see that would indeed be a problem. Are there future
plans to start tracking such dependencies? It seems like it would
be a good idea in general.
I believe the EXECUTE statement would thwart such plans.
--
Sent via pgsql-gener
On Thu, Aug 28, 2008 at 5:32 PM, Christophe <[EMAIL PROTECTED]> wrote:
> On Aug 28, 2008, at 3:21 PM, Matthew Dennis wrote:
>
>> I have no doubt that someone would complain about it, but I think it's
>> better than the alternative.
>>
>
> Determining if changing any function will cause an index to
On Thu, Aug 28, 2008 at 6:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Matthew Dennis" <[EMAIL PROTECTED]> writes:
> > On Thu, Aug 28, 2008 at 9:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> (Changing the behavior of an allegedly IMMUTABLE function has a number
> >> of other pitfalls besides th
"Matthew Dennis" <[EMAIL PROTECTED]> writes:
> On Thu, Aug 28, 2008 at 9:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> (Changing the behavior of an allegedly IMMUTABLE function has a number
>> of other pitfalls besides that one, btw.)
> I'm interested in knowing what they are - could you point me
On Aug 28, 2008, at 3:21 PM, Matthew Dennis wrote:
I have no doubt that someone would complain about it, but I think
it's better than the alternative.
Determining if changing any function will cause an index to break is
not a straight-forward problem. I don't believe that PG right now
kee
On Thu, Aug 28, 2008 at 9:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> (Changing the behavior of an allegedly IMMUTABLE function has a number
> of other pitfalls besides that one, btw.)
>
I'm interested in knowing what they are - could you point me in the right
direction (I've read the docs on im
On Thu, Aug 28, 2008 at 9:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> If it did that, you (or someone) would complain about the enormous
> overhead imposed on trivial updates of the function. Since determining
> whether the function actually did change behavior is Turing-complete,
> we can't rea
Tom Lane <[EMAIL PROTECTED]> writes:
> Since determining whether the function actually did change behavior is
> Turing-complete, we can't realistically try to determine that in software.
> So we leave it up to the user to reindex if he makes a behavioral change in
> an indexed function.
Another
"Matthew Dennis" <[EMAIL PROTECTED]> writes:
> Given table T(c1 int) and function F(arg int) create an index on T using
> F(c1). It appears that if you execute "create or replace function F" and
> provide a different implementation that the index still contains the results
> from the original impl
22 matches
Mail list logo
