On 06/21/2017 06:06 AM, Pierre Ducroquet wrote:
Please reply to list also.
Ccing list.
> On Wednesday, June 21, 2017 5:49:29 AM CEST you wrote:
>> On 06/21/2017 04:28 AM, Pierre Ducroquet wrote:
>>> Hi
>>>
>>>
>>> I found a workaround using event triggers to rewrite every function when
>>> an
>>> alter occurs on such a table, but this seems… odd to me. I don't think we
>>> are doing anything very complicated here, so I'm surprised that nothing
>>> has been done yet to fix that issue.
>>
>> https://www.postgresql.org/docs/9.6/static/plpgsql-statements.html#PLPGSQL-S
>> TATEMENTS-EXECUTING-DYN
>>> Did I miss something obvious, or should I report that as a bug and start
>>> digging PostgreSQL code ?
>>
>> https://www.postgresql.org/docs/9.6/static/plpgsql-implementation.html#PLPGS
>> QL-PLAN-CACHING
>>> Thanks
>
> Hi Adrian
>
> I know this caching behavior is well-known and documented, and a disturbed way
> of writing triggers will fix it (prefixing every statement with EXECUTE would
> make for even uglier procedures), but still it seems counter-intuitive and
> could deserve being called a bug, or a serious restriction.
> I was very surprised to be hit by this so easily. Also, even after a backend
> was hit by a failure, it kept running the wrong plan until I forced a new
> function version. Hence my questioning, is there more than just «plpgsql cache
> plans» in that issue…
> If there is nothing else, then I'll start digging the code…
I don't know, which is why I am returning this to list.
>
> Pierre
>
--
Adrian Klaver
adrian.klaver@aklaver.com
