| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | marc(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 15:58:56 |
| Message-ID: | 1396479.1606838336@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> In 12.5 (and later), in a clean, empty database (in this case the default
> 12.5 docker image), when I execute the following lines:
> create table xx (name text NOT NULL default '', PRIMARY KEY(name));
> create temporary table xx
> (like xx including DEFAULTS including CONSTRAINTS including INDEXES);
Hm, interesting. 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);
The ordering of these operations got rearranged recently to fix some
other bugs, so it doesn't surprise me if it used to work differently.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-12-01 17:07:41 | Re: BUG #16758: create temporary table with the same name loses defaults, indexes |
| Previous Message | Tom Lane | 2020-12-01 15:24:51 | Re: BUG #16755: A specification or a bug? Digit drop on CAST from DOUBLE PRECISION to NUMERIC. |