Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1tI9ii-00CXn0-FE
	for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Dec 2024 16:56:24 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1tI9if-001Utz-DZ
	for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Dec 2024 16:56:22 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1tI9if-001Utr-3s
	for pgsql-hackers@lists.postgresql.org; Mon, 02 Dec 2024 16:56:22 +0000
Received: from sss.pgh.pa.us ([68.162.161.243])
	by makus.postgresql.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1tI9id-000gRa-NZ
	for pgsql-hackers@lists.postgresql.org; Mon, 02 Dec 2024 16:56:21 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 4B2GuG7q1645312;
	Mon, 2 Dec 2024 11:56:16 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Vik Fearing <vik@postgresfriends.org>
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>
Subject: Re: CREATE SCHEMA ... CREATE DOMAIN support
In-reply-to: <5a329e21-2f07-4ec7-bcbf-32b9445ed127@postgresfriends.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>
Comments: In-reply-to Vik Fearing <vik@postgresfriends.org>
	message dated "Mon, 02 Dec 2024 17:08:26 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1645310.1733158576.1@sss.pgh.pa.us>
Date: Mon, 02 Dec 2024 11:56:16 -0500
Message-ID: <1645311.1733158576@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: <https://www.postgresql.org/message-id/1645311.1733158576%40sss.pgh.pa.us>
Precedence: bulk

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.  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.

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.)  I don't know offhand if the
spec allows function overloading in the same way.

			regards, tom lane