Re: Postgresql9.6 type cache invalidation issue - different behave of psql and pg regress

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgresql9.6 type cache invalidation issue - different behave of psql and pg regress
Date: 2018-04-20 18:08:48
Message-ID: CAFj8pRCfWmcXuCDuAkHAv7P9iNvvV_+-P4x2pE3UYCuO0U-QOg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2018-04-20 15:44 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > In interactive mode, the build_row_from_class has unrefreshed metadata.
> But
> > why this behave I see only in psql and not in my regress tests?
>
> The short answer is that no plpgsql version before commit 4b93f5799
> will have nice behavior for cases where you change a referenced composite
> type between calls. Why that's translating to the particular behavior
> you're seeing isn't clear, considering you showed only one case in
> detail; but I imagine it's because a parse of the plpgsql function
> happens before the ALTER TABLE in one case and not the other.
> Perhaps you have different settings of check_function_bodies,
> for instance.
>

good catch - I had check_function_bodies disabled.

Thank you for reply. Now I can believe to my regress tests again :)

Regards

Nice weekend

Pavel

> regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-04-20 18:19:55 Re: Should we add GUCs to allow partition pruning to be disabled?
Previous Message Pavel Stehule 2018-04-20 17:45:06 Re: [HACKERS] proposal: schema variables