From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: allow building trusted languages without the untrusted versions
In-reply-to: <20220523173805.GB939874@nathanxps13>
References: <20220520225619.GA876272@nathanxps13>
 <571753.1653092411@sss.pgh.pa.us> <20220523165403.GC938919@nathanxps13>
 <1290329.1653326228@sss.pgh.pa.us> <20220523173805.GB939874@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Mon, 23 May 2022 10:38:05 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1306837.1653330002.1@sss.pgh.pa.us>
Date: Mon, 23 May 2022 14:20:02 -0400
Message-ID: <1306838.1653330002@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1306838.1653330002%40sss.pgh.pa.us>
Precedence: bulk

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.

			regards, tom lane