Moving this over to -hackers and the commitfest
https://www.postgresql.org/message-id/CAKFQuwaZjsaQ9KdDKjcwgGo3axg2t0BdBVYJiHf%3DH9nbvsxQbQ%40mail.gmail.com
David J.
On Thu, Oct 1, 2020 at 5:14 PM David G. Johnston
wrote:
> On Wed, Sep 30, 2020 at 7:41 AM Tom Lane wrote:
>
>> If you really r
On Wed, Sep 30, 2020 at 7:41 AM Tom Lane wrote:
> If you really really need to do this, I'd counsel using EXECUTE to
> ensure no caching happens. But I concur with Michael that it's
> fundamentally a bad idea.
>
Agreed, though the documentation seems a bit loose here. The fact that the
temp ta
Michael Lewis writes:
> IMO, you are asking for strange behavior when you overload a table name.
> I expect that one of the people who work down deep down in the code will
> say it is a caching thing that saves system table lookups.
Yeah, I think that on the second call, plpgsql caches a query p
On Wed, Sep 30, 2020, 7:27 AM v.br...@joinsnc.com
wrote:
>
> Hi all,
> I have this strange behavior when I use temp table with same name of a
> permanent table in a function.
>
IMO, you are asking for strange behavior when you overload a table name.
I expect that one of the people who work down
Hi all,
I have this strange behavior when I use temp table with same name of a
permanent table in a function.
Postgres version is:
PostgreSQL 11.3 (Debian 11.3-1.pgdg90+1) on x86_64-pc-linux-gnu,
compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit
I use a query panel from pgAdmin
