From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marc Boeren <m(dot)boeren(at)guidance(dot)nl> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16758: create temporary table with the same name loses defaults, indexes |
Date: | 2020-12-01 17:07:41 |
Message-ID: | 1399710.1606842461@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
[ please keep the mailing list cc'd ]
Marc Boeren <m(dot)boeren(at)guidance(dot)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 code.
Thanks for confirming the diagnosis!
> Not sure if it's a bug worth fixing, but perhaps a mention in the documentation?
No, it's definitely a bug IMO. The change in behavior was not
intentional.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-12-01 20:58:43 | Re: BUG #16754: When using LLVM and parallel queries aborted all session by pg_cancel_backend. |
Previous Message | Tom Lane | 2020-12-01 15:58:56 | Re: BUG #16758: create temporary table with the same name loses defaults, indexes |