Message-ID: <5a329e21-2f07-4ec7-bcbf-32b9445ed127@postgresfriends.org>
Date: Mon, 2 Dec 2024 17:08:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: CREATE SCHEMA ... CREATE DOMAIN support
To: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>
Cc: jian he <jian.universality@gmail.com>,
 Kirill Reshke <reshkekirill@gmail.com>,
 Peter Eisentraut <peter@eisentraut.org>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <2007224.1732773174@sss.pgh.pa.us>
 <CALdSSPgftbtV=UyeK_XcLit_mKQZr+g8pCxA0kLLxDi0kKwEGw@mail.gmail.com>
 <CACJufxH5TvkQiMOJ9dpDrDbRtyCa-yu+QOmYGt4WGGYVrN+P8g@mail.gmail.com>
 <1075425.1732993688@sss.pgh.pa.us> <1220935.1733009604@sss.pgh.pa.us>
 <CALdSSPi1tgLgXjSJ7jgQ7L65iRkpuDFL2cJH2QYSz-Hhx3DBew@mail.gmail.com>
 <1273964.1733032384@sss.pgh.pa.us>
 <CACJufxEvYeyXZ9xj8f1A7cuMU4Fh4WF3Dg8HnArLSkwYbqKO3A@mail.gmail.com>
 <1353043.1733072243@sss.pgh.pa.us> <1488327.1733092220@sss.pgh.pa.us>
 <Z00OwQVHY4DfjVSA@paquier.xyz> <1525354.1733105723@sss.pgh.pa.us>
Content-Language: en-US
From: Vik Fearing <vik@postgresfriends.org>
In-Reply-To: <1525354.1733105723@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/5a329e21-2f07-4ec7-bcbf-32b9445ed127%40postgresfriends.org>
Precedence: bulk


On 02/12/2024 03:15, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> 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?
> I don't see where you're getting that from?  DB2 says that unqualified
> reference names (not to be confused with unqualified creation-target
> names) are taken to be in the new schema, but I don't see any
> corresponding restriction in the spec.
>
> What I do see (11.1 SR 6 in SQL:2021) is:
>
>      If <schema path specification> is not specified, then a <schema
>      path specification> containing an implementation-defined <schema
>      name list> that contains the <schema name> contained in <schema
>      name clause> is implicit.
>
> What I read this as is that the "search path" during schema-element
> creation must include at least the new schema, but can also include
> some other schemas as defined by the implementation.  That makes
> our behavior compliant, because we can define the other schemas
> as those in the session's prevailing search_path.  (DB2's behavior
> is also compliant, but they're defining the path as containing only
> the new schema.)
>
> Also, if SQL intended to constrain the search path for unqualified
> identifiers to be only the new schema, they'd hardly need a concept
> of <schema path specification> at all.


I looked up the original paper (MUN-051) that introduced the <schema 
path specification> and it says, "The paper is proposing the use of 
paths only to resolve unqualified routine invocations."


That doesn't seem to have been explained much by the rest of the spec, 
but it is visible in the definition of <path specification> which says, 
"Specify an order for searching for an SQL-invoked routine."


I can find nowhere that says that the path can or cannot be used for 
other objects.

-- 

Vik Fearing