Message-ID: <5b918548-605a-40c0-9ff0-82038608ab7c@postgresfriends.org>
Date: Mon, 2 Dec 2024 18:26:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: CREATE SCHEMA ... CREATE DOMAIN support
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>,
 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>
 <5a329e21-2f07-4ec7-bcbf-32b9445ed127@postgresfriends.org>
 <1645311.1733158576@sss.pgh.pa.us>
Content-Language: en-US
From: Vik Fearing <vik@postgresfriends.org>
In-Reply-To: <1645311.1733158576@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/5b918548-605a-40c0-9ff0-82038608ab7c%40postgresfriends.org>
Precedence: bulk


On 02/12/2024 17:56, Tom Lane wrote:
> Vik Fearing <vik@postgresfriends.org> writes:
>> On 02/12/2024 03:15, Tom Lane wrote:
>>> 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."
> Interesting.


The standard actually does say that that is what it is for.

Section 11.1 <schema definition> SR 8:

"The <schema name list> of the explicit or implicit <schema path 
specification> is used as the SQL- path of the schema. The SQL-path is 
used to effectively qualify unqualified <routine name>s that are 
immediately contained in <routine invocation>s that are contained in the 
<schema definition>."


> But still, the spec allows <schema routine> within
> <schema definition>, so even that narrow interpretation opens them
> to the is-this-an-external-reference-or-a-forward-reference problem.


Surely that is determined by the placement of the schema in its own 
SQL-path.


> For us, that's clouded further for functions by our overloading rules.
> If foo(bigint) exists in the search path, and we have a view or
> whatever that references foo() with an int argument, and there is a
> CREATE FUNCTION for foo(float8) later in the <schema definition>, what
> are we supposed to think is the user's intent?  (Just to save people
> doing the experiment: we'd prefer foo(float8) if both are visible,
> but foo(bigint) would be perfectly acceptable if not.  Other choices
> of the argument types would yield different results, and none of them
> seem especially open-and-shut to me.)


My answer is the same as above, for unqualified names.


However, since there is nothing that says anything either way about 
forward references, my preference is to just execute them all in the 
order written.  In your example, that would mean choosing 
otherschema.foo(bigint) over thisschema.foo(float8) if the latter hasn't 
been created yet.


> I don't know offhand if the
> spec allows function overloading in the same way.


Feature T-321 has a note saying, "Support for overloaded functions and 
procedures is not part of Core SQL."

-- 

Vik Fearing