From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, 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: | 2024-12-02 01:34:57 |
Message-ID: | Z00OwQVHY4DfjVSA@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Dec 01, 2024 at 05:30:20PM -0500, Tom Lane wrote:
> Which certainly begs the question of how smart their re-ordering
> algorithm is, or what they do about ambiguity between new and existing
> objects.
Perhaps because they are able to track efficiently all schema
references, like checking the internal of functions at creation time
rather than just at runtime? The ambiguity between new and existing
objects may be tricky, indeed.
If I'm parsing the spec right, the doc mentions in its 5)~6) of the
syntax rules in CREATE SCHEMA that non-schema-qualified objects should
use the new schema name defined in the CREATE SCHEMA query. So that
pretty much settles the rules to use when having a new object that has
a reference to a non-qualified object created in the same CREATE
SCHEMA query?
> But at any rate, it looks like everybody is at least trying
> to do some amount of re-ordering, which makes me wonder what it is
> that I'm missing in the spec. That's an awful lot of effort to be
> expending on something that the spec doesn't seem to require.
As Jian has mentioned, 9075-2-2023 around 11.1 for CREATE SCHEMA does
not include any ordering assumptions when the elements are created, so
my guess is that this is left up to each implementation depending on
how they need to handle their dependencies with their meta-data
lookup? The result would be the same once the query has finished
running, as long as the elements created are consistent with their
inner dependencies.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michail Nikolaev | 2024-12-02 01:39:00 | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
Previous Message | Andy Fan | 2024-12-02 01:03:28 | Re: Code cleanup for detoast a expanded datum. |