Re: allow building trusted languages without the untrusted versions - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: allow building trusted languages without the untrusted versions
Date
Msg-id 20220523183457.GA940868@nathanxps13
Whole thread Raw
In response to Re: allow building trusted languages without the untrusted versions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: allow building trusted languages without the untrusted versions
Next
From: Robert Haas
Date:
Subject: Re: allow building trusted languages without the untrusted versions