Date: Mon, 23 May 2022 11:34:57 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: allow building trusted languages without the untrusted versions
Message-ID: <20220523183457.GA940868@nathanxps13>
References: <20220520225619.GA876272@nathanxps13>
 <571753.1653092411@sss.pgh.pa.us>
 <20220523165403.GC938919@nathanxps13>
 <1290329.1653326228@sss.pgh.pa.us>
 <20220523173805.GB939874@nathanxps13>
 <1306838.1653330002@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1306838.1653330002@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20220523183457.GA940868%40nathanxps13>
Precedence: bulk

On Mon, May 23, 2022 at 02:20:02PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> That's a reasonable point.  I'll go ahead an explore some options for
>> something along those lines.  A couple of questions immediately come to
>> mind.  For example, should this configuration option just cause these
>> functions to ERROR, or should it compile them out?
> 
> Letting them be present but throw error is likely to be far less
> painful than the other way, because then you don't need a separate
> set of SQL-visible object definitions.  You could, in fact, imagine
> jacking up an existing database and driving a set of locked-down
> binaries under it --- or vice versa.  If there have to be different
> versions of the extension SQL files for the two cases then everything
> gets way hairier, both for developers and users.

Agreed.  I'll do it that way.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com