From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Lewis <mlewis(at)entrata(dot)com> |
Cc: | v(dot)brusa(at)joinsnc(dot)com, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: temp table same name real table |
Date: | 2020-09-30 14:41:29 |
Message-ID: | 841734.1601476889@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Michael Lewis <mlewis(at)entrata(dot)com> 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 plan that
references the permanent table, and then it sees no reason to reconsider
that plan on the third call. (Change of search_path is one of the
conditions that would prompt throwing away the cached plan, which
fits that part of the report. But creating a temp table that happens
to shadow a real table is not one.)
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2020-09-30 15:26:39 | Re: Problem close curser after rollback |
Previous Message | Devrim Gündüz | 2020-09-30 14:39:51 | Re: Yum repository RPM behind release |