From: Tom Lane <tgl@sss.pgh.pa.us>
To: Marc Boeren <m.boeren@guidance.nl>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16758: create temporary table with the same name loses
 defaults, indexes
In-reply-to: <B16D4C9A-2E12-4154-A628-CA239E0A3DA5@guidance.nl>
References: <16758-840e84a6cfab276d@postgresql.org>
 <1396479.1606838336@sss.pgh.pa.us>
 <B16D4C9A-2E12-4154-A628-CA239E0A3DA5@guidance.nl>
Comments: In-reply-to Marc Boeren <m.boeren@guidance.nl>
	message dated "Tue, 01 Dec 2020 16:26:40 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1399709.1606842461.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 01 Dec 2020 12:07:41 -0500
Message-ID: <1399710.1606842461@sss.pgh.pa.us>
Precedence: bulk

[ please keep the mailing list cc'd ]

Marc Boeren <m.boeren@guidance.nl> writes:
>> Without having dug into the code, I bet what is
>> happening is that after creating pg_temp.xx, the LIKE code is looking
>> to see "what indexes exist on table xx?", to which the answer is "none"
>> because it finds pg_temp.xx.  We need to nail down the schema in which
>> xx is sought for that step.  As a workaround, you could nail down the
>> schema manually:
>> =

>> create temporary table xx (like public.xx including DEFAULTS including
>> CONSTRAINTS including INDEXES);

> This workaround works both on the example code, and on my production cod=
e.

Thanks for confirming the diagnosis!

> Not sure if it's a bug worth fixing, but perhaps a mention in the docume=
ntation?

No, it's definitely a bug IMO.  The change in behavior was not
intentional.

			regards, tom lane