> david.g.johns...@gmail.com wrote:
>
> b...@yugabyte.com wrote:
>>
>> Meanwhile. I'll appeal for some pointers to what I should read...
>
> I tend not to search...or at least that isn't my first (or at least only)
> recourse. The pg/pgsql chapter has a subchapter named "Plan Caching":
>
>
On Wed, Jun 29, 2022 at 5:03 PM Bryn Llewellyn wrote:
>
> *Meanwhile. I'll appeal for some pointers to what I should read:*
> I *had* understood that the SQL that a user-created subprogram issues (at
> least for "language sql" and "language plpgsql") is implicitly prepared.
> But I've no idea
> david.g.johns...@gmail.com wrote:
>
>> b...@yugabyte.com wrote:
>>
>> When I drop the first link, f1() in the chain of "immutable" functions, I
>> see that I cannot invoke f(2) because it now complains that f1() doesn't
>> exist. This surprises me because, after all, the result of f2() is
On Wednesday, June 29, 2022, Bryn Llewellyn wrote:
>
> When I drop the first link, f1() in the chain of "immutable" functions, I
> see that I cannot invoke f(2) because it now complains that f1() doesn't
> exist. This surprises me because, after all, the result of f2() is now
> cached (at least
> x...@thebuild.com wrote:
>
> I think "not allowed" is putting it too strongly. It would be a bit much to
> ask that every single user-written immutable function be 100% perfect when it
> is rolled out, and never have to fix any bugs in them. However, you
> definitely *do* have to understand
> On Jun 28, 2022, at 23:42, Laurenz Albe wrote:
> That is not enough in the general case. You are not allowed to redefine
> an IMMUTABLE function in a way that changes its behavior [...]
I think "not allowed" is putting it too strongly. It would be a bit much to
ask that every single
st 29. 6. 2022 v 8:29 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > st 29. 6. 2022 v 7:46 odesílatel Tom Lane napsal:
> >> ... that result has discouraged most people from spending much
> >> time on mechanically checking such things. If you declare a function
> >> immutable,
On Tue, 2022-06-28 at 19:02 -0700, Christophe Pettus wrote:
> > On Jun 28, 2022, at 18:41, Bryn Llewellyn wrote:
> > Should I simply understand that when I have such a dynamic dependency
> > chain of "immutable" functions, and should I drop and re-create the
> > function at the start of the
Pavel Stehule writes:
> st 29. 6. 2022 v 7:46 odesílatel Tom Lane napsal:
>> ... that result has discouraged most people from spending much
>> time on mechanically checking such things. If you declare a function
>> immutable, Postgres will believe you; the consequences if you lied
>> are on
st 29. 6. 2022 v 7:46 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > st 29. 6. 2022 v 6:28 odesílatel Bryn Llewellyn
> napsal:
> >> Moreover, this "hermetic" property of a to-be-immutable function can be
> >> established only by human analysis of the function's source code.
>
> > Our
Pavel Stehule writes:
> st 29. 6. 2022 v 6:28 odesílatel Bryn Llewellyn napsal:
>> Moreover, this "hermetic" property of a to-be-immutable function can be
>> established only by human analysis of the function's source code.
> Our immutable functions are more tolerant than they should be - for
On Tuesday, June 28, 2022, Bryn Llewellyn wrote:
>
> DISCARD PLANS is unsafe in a multi-user concurrent scenario. The doc says
> explicitly that its scope is just the single session. And it's easy to show
> the danger by using my testcase manually, step by appropriate step, with
> two concurrent
st 29. 6. 2022 v 6:28 odesílatel Bryn Llewellyn napsal:
> *david.g.johns...@gmail.com wrote:*
>
>
> *x...@thebuild.com wrote:*
>
> b...@yugabyte.com wrote:
>
> Should I simply understand that when I have such a dynamic dependency
> chain of "immutable" functions, and should I drop and
> david.g.johns...@gmail.com wrote:
>
>> x...@thebuild.com wrote:
>>
>>> b...@yugabyte.com wrote:
>>>
>>> Should I simply understand that when I have such a dynamic dependency chain
>>> of "immutable" functions, and should I drop and re-create the function at
>>> the start of the chain, then
On Tue, Jun 28, 2022 at 7:03 PM Christophe Pettus wrote:
>
>
> > On Jun 28, 2022, at 18:41, Bryn Llewellyn wrote:
> > Should I simply understand that when I have such a dynamic dependency
> chain of "immutable" functions, and should I drop and re-create the
> function at the start of the chain,
> On Jun 28, 2022, at 18:41, Bryn Llewellyn wrote:
> Should I simply understand that when I have such a dynamic dependency chain
> of "immutable" functions, and should I drop and re-create the function at the
> start of the chain, then all bets are off until I drop and re-create every
>
I’ve copied my self-contained testcase at the end.
I create three functions, marking each of them "immutable". "f1()" simply
returns the manifest constant 'dog'. So it seems perfectly honest to mark it as
I did. "f2()" simply returns "f1()"—so, here too, it seems that I'm being
honest. But I
17 matches
Mail list logo
