| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com> |
| Cc: | Kirill Reshke <reshkekirill(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: CREATE SCHEMA ... CREATE DOMAIN support |
| Date: | 2026-04-03 18:35:22 |
| Message-ID: | 3819788.1775241322@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote [ many months ago now ]:
>> I think this is still kind of blocked, because it's not clear to me
>> whether we have consensus about it being okay to do 0001.
>>
>> Re-reading the thread, the only real use-case for re-ordering that
>> anyone proposed is that foreign key references should be able to be
>> forward references to tables created later in the same CREATE SCHEMA.
>> I concede first that this is a somewhat-plausible use-case and
>> second that it is pretty clearly required by spec. The fact remains
>> however that we have never supported that in two dozen years, and
>> the number of complaints about the omission could be counted without
>> running out of thumbs. So, how about the following plan of action?
>>
>> 1. Rip out subcommand re-ordering as currently implemented, and do the
>> subcommands in the given order.
>>
>> 2. When a CREATE TABLE subcommand includes a FOREIGN KEY clause,
>> transform that clause into ALTER TABLE ADD FOREIGN KEY, and push
>> it to the back of the CREATE SCHEMA's to-do list.
Nobody has complained about this approach since September, so unless
there's a complaint PDQ, I'm going to take silence as consent and
move forward with reviewing/applying Jian's patchset.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-04-03 19:01:05 | Re: EXPLAIN: showing ReadStream / prefetch stats |
| Previous Message | Tom Lane | 2026-04-03 18:20:32 | Re: pg_plan_advice |