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 1scoxw-00AiAa-Fe for pgsql-hackers@arkaria.postgresql.org; Sat, 10 Aug 2024 16:29:16 +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 1scoxu-009dQB-2q for pgsql-hackers@arkaria.postgresql.org; Sat, 10 Aug 2024 16:29:14 +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 1scoxt-009dQ3-Nh for pgsql-hackers@lists.postgresql.org; Sat, 10 Aug 2024 16:29:13 +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 1scoxm-004418-KW for pgsql-hackers@lists.postgresql.org; Sat, 10 Aug 2024 16:29:12 +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 47AGT4OC3155778; Sat, 10 Aug 2024 12:29:04 -0400 From: Tom Lane To: "David G. Johnston" cc: Stepan , "pgsql-hackers@lists.postgresql.org" Subject: Re: SPI_connect, SPI_connect_ext return type In-reply-to: References: <3133982.1723299124@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Sat, 10 Aug 2024 08:18:31 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3155776.1723307344.1@sss.pgh.pa.us> Date: Sat, 10 Aug 2024 12:29:04 -0400 Message-ID: <3155777.1723307344@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Saturday, August 10, 2024, Tom Lane wrote: >> That would break a lot of code (much of it not under our control) to >> little purpose; it would also foreclose the option to return to using >> SPI_ERROR_CONNECT someday. > I suggest we document it as deprecated and insist any future attempt to > implement a return-on-error connection function define a completely new > function. True; we're kind of in an intermediate place right now where certain call sites aren't bothering to check the return code, but it's hard to argue that they're really wrong --- and more to the point, re-introducing use of SPI_ERROR_CONNECT would break them. I don't know if that usage pattern has propagated outside Postgres core, but it might've. Perhaps it would be better to update the docs to say that the only return value is SPI_OK_CONNECT and all failure cases are reported via elog/ereport. regards, tom lane