From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        Robert Haas <robertmhaas@gmail.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: allow building trusted languages without the untrusted versions
In-reply-to: <20220713185350.GA3118442@nathanxps13>
References: <1290329.1653326228@sss.pgh.pa.us>
 <CA+TgmoY-Xy_ObfYVUTSamD8BmW8npaktbr65JtnkW-c1VQobVA@mail.gmail.com>
 <1333860.1653338790@sss.pgh.pa.us>
 <CA+TgmoYZKLxftaZZvj4_-zHQ27CBeUs+KvggyU3qS79-7aQEPA@mail.gmail.com>
 <1354561.1653345768@sss.pgh.pa.us>
 <CA+TgmoZ_c0j4ut87_QCFm697Qq5Z_u66VZt2PYenfZVjUT1qRA@mail.gmail.com>
 <20220524172851.GA1191690@nathanxps13>
 <CA+TgmobOQiDXpYq6TgaCzH3p5c0Fko-wXqCjgd5YsR6RsX31vA@mail.gmail.com>
 <20220524205841.GA1254661@nathanxps13>
 <849661f1-85a3-2833-5477-059a9b58e70f@enterprisedb.com>
 <20220713185350.GA3118442@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Wed, 13 Jul 2022 11:53:50 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2476506.1657741774.1@sss.pgh.pa.us>
Date: Wed, 13 Jul 2022 15:49:34 -0400
Message-ID: <2476507.1657741774@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2476507.1657741774%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> Given the discussion in this thread, I intend to mark the commitfest entry
> as Withdrawn shortly.  Before I do, I thought I'd first check whether 0001
> [0] might be worthwhile independent of $SUBJECT.  This change separates the
> [un]trusted handler and validator functions for PL/Perl so that we no
> longer need to inspect pg_language to determine whether to use the trusted
> or untrusted code path.  I was surprised to learn that you can end up with
> PL/PerlU even if you've specified the trusted handler/validator functions.
> Besides bringing things more in line with how PL/Tcl does things, this
> change simplifies function lookup in plperl_proc_hash.  I suppose such a
> change might introduce a compatibility break for users who are depending on
> this behavior, but I don't know if that's worth worrying about.

Meh.  Avoiding the potential repeat hashtable lookup is worth something,
but I'm not sure I buy that this is a semantic improvement.  ISTM that
lanpltrusted *should* be the ultimate source of truth on this point.

My feelings about it are not terribly strong either way, though.

			regards, tom lane