Re: CREATE TABLE .. LIKE copies comments to an unrelated table

Hi Jim,

I tested v2 (CF entry 7379). Thank you for the patch. Here are my results.

## Setup

- I used the commitfest bot branch cf/7379, commit
b4fc3ecd05530dac85f0bb832e4386efa07f2696 ("[CF 7379] v2"). It contains
v2-0001 only.
- I built it on Linux under WSL with: --enable-cassert --enable-debug
--enable-tap-tests --without-icu.
- The build gave 0 compiler warnings.
- For comparison I used an unpatched master build (PostgreSQL
20devel). I ran the same SQL script on a fresh temporary cluster for
each build.

## Tests that passed

- make check: "All 243 tests passed", and create_table_like was ok.
- Your case from the first mail (column comment, search_path = public,
pg_temp): on master, public.foo got "col comment" and the temp foo got
none. With v2, public.foo keeps "important comment" and the temp foo
gets "col comment".
- Salma's NOT NULL constraint case: on master, CREATE TEMP TABLE foo2
(LIKE src2 INCLUDING COMMENTS) fails with: constraint
"src2_a_not_null" for table "foo2" does not exist. With v2 it
succeeds, and the column comment and the constraint comment ("nn
comment") are on the temp table. The permanent foo2 keeps its own
comment.
- LIKE ... INCLUDING ALL with a same-named permanent table (it has its
own primary key index comment and table comment): on master it fails
with: constraint "src3_b_chk" for table "foo3" does not exist. With v2
it succeeds. The temp table gets the copied index comment ("src pk
index") and the CHECK constraint comment ("src check"). The permanent
foo3 keeps "unrelated table" and "unrelated index".
- Default search_path (pg_temp implicitly first, no same-named table):
the copied CHECK constraint comment is the same on master and with v2.
- Permanent tables: I created a permanent dup5 in schema s5
(search_path = s5, public, pg_temp) while public.dup5 and pg_temp.dup5
also existed. The column comment was copied to s5.dup5 (I did not
check the constraint comment there), and public.dup5 kept its own
comment. The result was the same on master and with v2.
- A temp source table with LIKE ... INCLUDING COMMENTS and CREATE TEMP
TABLE IF NOT EXISTS ... ON COMMIT DROP, run twice in one transaction:
the first run copied the column and constraint comments, and the
second run only gave the "already exists, skipping" notice. The result
was the same on master and with v2.
- A temp table with INHERITS, and a temp partitioned table with a
partition, were created without errors with v2.
- A grep of the patched cluster's server log for ERROR, WARNING, TRAP
and PANIC found nothing. The master log had only the two errors
described above.

## Manual tests

The SQL script and the complete psql output for master and v2 are in
the log I kept (I can send it if useful). The cases are the ones
listed above.

## Not tested

- The concurrent rename of a temp schema discussed with Koshi (two
sessions, superuser). I did not run it. I agree with Jim's reasoning
that it does not need handling, but I did not verify the behaviour
myself.
- The TAP tests (only make check was run), other platforms, Windows,
and builds with ICU.
- Other LIKE options not listed above (for example INCLUDING
STATISTICS, GENERATED, IDENTITY), and temp tables created inside
functions or by other sessions.
- I did not measure performance, and I did not check other callers of
transformCreateStmt().

Overall, v2 behaves as described in the commit message in all the
cases I tried, and I found no problems.

Best regards,
João Rito