| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com> |
| Subject: | Re: psql: Fix CREATE SCHEMA scanning of nested routine bodies |
| Date: | 2026-06-23 18:16:52 |
| Message-ID: | 802054.1782238612@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> writes:
> Following your suggestion, I moved the "{identifier}" logic into a new helper psqlscan_track_identifier(), and added “create_schema_identifiers" to PsqlScanStateData to track identifiers from the current top-level CREATE element within CREATE SCHEMA in the same way as the top level “identifiers". I also added a few more test cases.
> Please see the attached v2 for details.
Pushed with some mostly-cosmetic changes. Notably, I renamed the
existing "identifiers" field to help distinguish it from the new one.
I didn't use your test cases because it seemed unduly expensive to do
it that way. We can perfectly well exercise this as part of plain-SQL
regression testing, so I just added a booby-trap case in
create_schema.sql. Without this fix, psql marches on and tries to run
the various \d commands after the CREATE SCHEMA before it's sent the
CREATE SCHEMA command. So even though no error is reported, the
output is quite different.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2026-06-23 18:30:33 | Re: [GSoC 2026] - B-tree Index Bloat Reduction - Approach & Questions |
| Previous Message | Paul A Jungwirth | 2026-06-23 18:16:47 | Re: Additional message in pg_terminate_backend |