Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lWnMl-0002p0-2d for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Apr 2021 21:48:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lWnMk-0005ma-0F for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Apr 2021 21:48:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lWnMj-0005mS-PF for pgsql-hackers@lists.postgresql.org; Wed, 14 Apr 2021 21:48:05 +0000 Received: from relay12.mail.gandi.net ([217.70.178.232]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lWnMe-0003Bh-Py for pgsql-hackers@lists.postgresql.org; Wed, 14 Apr 2021 21:48:04 +0000 Received: from [172.16.255.146] (14.149.88.79.rev.sfr.net [79.88.149.14]) (Authenticated sender: vik@postgresfriends.org) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 96333200004; Wed, 14 Apr 2021 21:47:54 +0000 (UTC) Subject: Re: Converting contrib SQL functions to new style To: Tom Lane , Mark Dilger Cc: PostgreSQL Hackers , Peter Eisentraut , Robert Haas References: <3395418.1618352794@sss.pgh.pa.us> <3565758.1618421782@sss.pgh.pa.us> From: Vik Fearing Message-ID: <564283e2-3ba5-54ac-1d6b-d86bef3d9dc9@postgresfriends.org> Date: Wed, 14 Apr 2021 23:47:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <3565758.1618421782@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 4/14/21 7:36 PM, Tom Lane wrote: > Mark Dilger writes: >>> On Apr 13, 2021, at 3:26 PM, Tom Lane wrote: >>> However I think we may still need an assumption that earthdistance >>> and cube are in the same schema --- any comments on that? > >> This is probably not worth doing, and we are already past feature >> freeze, but adding syntax to look up the namespace of an extension might >> help. > > Yeah, that idea was discussed before (perhaps only in private > security-team threads, though). We didn't do anything about it because > at the time there didn't seem to be pressing need, but in the context > of SQL function bodies there's an obvious use-case. > >> We could get something like this working just inside the CREATE EXTENSION command if we expanded on the @extschema@ idea a bit. At first I thought this idea would suffer race conditions with concurrent modifications of pg_extension or pg_namespace, but it looks like we already have a snapshot when processing the script file, so: > >> -CREATE DOMAIN earth AS cube >> +CREATE DOMAIN @@earthdistance@@::earth AS @@cube@@::cube > > Right, extending the @extschema@ mechanism is what was discussed, > though I think I'd lean towards something like @extschema:cube@ > to denote the schema of a referenced extension "cube". > > I'm not sure this is useful enough to break feature freeze for, > but I'm +1 for investigating it for v15. Just like we have a pseudo "$user" schema, could we have a pseudo "$extension" catalog? That should avoid changing grammar rules too much. CREATE TABLE unaccented_words ( word "$extension".citext.citext, CHECK (word = "$extension".unaccent.unaccent(word) ); -- Vik Fearing