Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rs4Fd-004bh5-Jd for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Apr 2024 17:18:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rs4Fc-005Mjp-OZ for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Apr 2024 17:18:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rs4Fc-005Mg1-F8 for pgsql-hackers@lists.postgresql.org; Wed, 03 Apr 2024 17:18:16 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rs4Fa-000OLU-3z for pgsql-hackers@lists.postgresql.org; Wed, 03 Apr 2024 17:18:15 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 433HI7oS149856; Wed, 3 Apr 2024 13:18:07 -0400 From: Tom Lane To: Corey Huinker cc: Jeff Davis , Magnus Hagander , Stephen Frost , Ashutosh Bapat , Matthias van de Meent , Peter Smith , PostgreSQL Hackers , Tomas Vondra Subject: Re: Statistics Import and Export In-reply-to: References: <54f190b6c757da2a33cce811949e9dd9601fcba7.camel@j-davis.com> <1632327b74a734f8c434eb75e824160d2b06a697.camel@j-davis.com> <16412b8b7ae443cb7470006beff3011927048860.camel@j-davis.com> <1b1bd1ec39ab3de09a17bf7b241021067e5bd63c.camel@j-davis.com> <2bce855db8259c5672a09f863a307ca07b967b68.camel@j-davis.com> <5e94c358caedf2a231dd71624c3578db7227a265.camel@j-davis.com> <718fa933c2c58d0ecc6! 1995ab5c7ca1fe78d6369.camel@j-davis.com> <790773.1711910899@sss.pgh.pa.us> <8bc6ffe1e5abeac0fdde1a83d95409f0463af013.camel@j-davis.com> <1141637.1711994977@sss.pgh.pa.us> <1215956.1711999455@sss.pgh.pa.us> <1321788.1712005745@sss.pgh.pa.us> <1328631.1712008078@sss.pgh.pa.us> <7d37175cd5b56ab04940ed6b5a72354ae90783ee.camel@j-davis.com> <1841621.1712093467@sss.pgh.pa.us> <06286ee47fa4b06b6e7f08da21958d7e35525ed4.camel@j-davis.com> <18! 46403.1712096333@sss.pgh.pa.us> Comments: In-reply-to Corey Huinker message dated "Wed, 03 Apr 2024 00:59:10 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <149854.1712164687.1@sss.pgh.pa.us> Date: Wed, 03 Apr 2024 13:18:07 -0400 Message-ID: <149855.1712164687@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Corey Huinker writes: > - functions strive to not ERROR unless absolutely necessary. The biggest > exposure is the call to array_in(). As far as that goes, it shouldn't be that hard to deal with, at least not for "soft" errors which hopefully cover most input-function failures these days. You should be invoking array_in via InputFunctionCallSafe and passing a suitably-set-up ErrorSaveContext. (Look at pg_input_error_info() for useful precedent.) There might be something to be said for handling all the error cases via an ErrorSaveContext and use of ereturn() instead of ereport(). Not sure if it's worth the trouble or not. regards, tom lane