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 1oBhVk-0003oJ-GR for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Jul 2022 18:55:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oBhUk-0007wc-T4 for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Jul 2022 18:53:58 +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 1oBhUk-0007wM-IU for pgsql-hackers@lists.postgresql.org; Wed, 13 Jul 2022 18:53:58 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oBhUf-0000RL-IY for pgsql-hackers@postgresql.org; Wed, 13 Jul 2022 18:53:57 +0000 Received: by mail-pj1-x1029.google.com with SMTP id o15so13373547pjh.1 for ; Wed, 13 Jul 2022 11:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hrBzAUzdZ3lCg9Cl9iK/lkczkWOJqd4Kwi14qWBbAs8=; b=K9+/1hQlRdj+l/2yqGC1UA1sw/NA28Ruc/k0rlkwIxl5KkjOVLB9O5VJViBV3OZXvT yNJR1n+BNzZSFje4eCtfpuWcmstqA+lH/ajF9uIVqaCXzF5qkqgaegwXShGqHELzhzat ww9e7sDhSP0fp/NelemcUZ9Rdqiec8DYAkVp+uFWgMETXr9lOFLkVvDTQgBNPYFsowBA CL3zsFLUaXUYqY8uu6gAeI+2ycM5Yd8ZARg3rtVCKw4KN1zOg6ldcoJ5eH/rdoEKYK5k p2pb92H4F3GSd86UgMHaRBB44R1Gil5fIkMM5Bq2RMtAFcvSfokQKUdyEmh6mX/H/7EJ EEWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hrBzAUzdZ3lCg9Cl9iK/lkczkWOJqd4Kwi14qWBbAs8=; b=4pdfN4f401jmPb9byBzsaeW08ip6R5+DjvjrIDqsl3TuUvzIaz7BQ+42GD414RwOoQ Ga0/Os+cHWTvnlj8HXzVisp1+ktj8/spEx8qLdJO8e5o9gINqsSUrnzIHSz2VJSUcUu8 BaAGysqYgTDJKB2oMEd4EguMhfnzQp8WmT6rq26sfjKnlLTp6WDIY/sq5HqPn5DWXoKP Br7gf3MeiJilsp89j33ljppyiE6vTzLbRxR06+NFndWP7SIvJydDVh4jxnnydfhN/r9H gBKKzrqpbQO9C4/afNU2SmdWYWxovUuvWXs65ygjVBvAuASms1kx6ZOr0W3xWY9Cr+wy YdTA== X-Gm-Message-State: AJIora/xYysr0vWH5nUBV/c61G8bR3x7SxbpmqVYIV1Mc80dxlaelfTw JQLHrpqpOsAktbusXnQY6Q4= X-Google-Smtp-Source: AGRyM1vqh24gm3P2Eb78NxQNZ9AwZcuiVeRrgK9USOminACl911rbz31TZ3USZYzJFyVCsU2G2PG7Q== X-Received: by 2002:a17:902:f64c:b0:16c:131:73ff with SMTP id m12-20020a170902f64c00b0016c013173ffmr4340105plg.170.1657738432362; Wed, 13 Jul 2022 11:53:52 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id rw9-20020a17090b2c4900b001ef8de342b8sm1998677pjb.15.2022.07.13.11.53.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Jul 2022 11:53:51 -0700 (PDT) Date: Wed, 13 Jul 2022 11:53:50 -0700 From: Nathan Bossart To: Peter Eisentraut Cc: Robert Haas , Tom Lane , "pgsql-hackers@postgresql.org" Subject: Re: allow building trusted languages without the untrusted versions Message-ID: <20220713185350.GA3118442@nathanxps13> References: <1290329.1653326228@sss.pgh.pa.us> <1333860.1653338790@sss.pgh.pa.us> <1354561.1653345768@sss.pgh.pa.us> <20220524172851.GA1191690@nathanxps13> <20220524205841.GA1254661@nathanxps13> <849661f1-85a3-2833-5477-059a9b58e70f@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <849661f1-85a3-2833-5477-059a9b58e70f@enterprisedb.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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. [0] https://www.postgresql.org/message-id/attachment/133940/v1-0001-Do-not-use-pg_language-to-determine-whether-PL-Pe.patch -- Nathan Bossart Amazon Web Services: https://aws.amazon.com