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 1mT6yB-00083D-AD for pgsql-bugs@arkaria.postgresql.org; Wed, 22 Sep 2021 18:27:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mT6y9-0005F1-7A for pgsql-bugs@arkaria.postgresql.org; Wed, 22 Sep 2021 18:27:45 +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 1mT6y9-0005Es-0N for pgsql-bugs@lists.postgresql.org; Wed, 22 Sep 2021 18:27:45 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mT6y6-00051q-Sp for pgsql-bugs@postgresql.org; Wed, 22 Sep 2021 18:27:44 +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 18MIRfnN2221000; Wed, 22 Sep 2021 14:27:41 -0400 From: Tom Lane To: Daniele Varrazzo cc: pgsql-bugs Subject: Re: Internal error with types changes and prepared statements In-reply-to: References: Comments: In-reply-to Daniele Varrazzo message dated "Wed, 22 Sep 2021 20:13:21 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2220998.1632335261.1@sss.pgh.pa.us> Date: Wed, 22 Sep 2021 14:27:41 -0400 Message-ID: <2220999.1632335261@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Daniele Varrazzo writes: > BEGIN; > CREATE TYPE an_enum AS ENUM ('foo', 'bar', 'baz'); > CREATE TABLE foo(id integer, bar an_enum[]); > PREPARE stmt (an_enum[]) AS INSERT INTO foo (bar) VALUES ($1); > EXECUTE stmt ('{foo}'); > ROLLBACK; > BEGIN; > CREATE TYPE an_enum AS ENUM ('foo', 'bar', 'baz'); > CREATE TABLE foo(id integer, bar an_enum[]); > EXECUTE stmt ('{foo}'); > ERROR: cache lookup failed for type 8072147 Hmm. We have not historically discarded prepared statements at ROLLBACK. While this example suggests it'd be safer to do so, I'm quite afraid that we would break a lot more applications than we'd fix. Actually ... you don't need the ROLLBACK anyway. You can reproduce this behavior by dropping and recreating the type/table. I'm inclined to shrug and say don't do that. We could perhaps track all the dependencies of a prepared statement as we do for views, but it would add a lot of overhead that's not there today, and for what? All we'd accomplish is to give a cleaner error message. I don't think people should expect the above to somehow work --- if it did, that would imply assorted security holes, because the statement would no longer mean what it meant before. regards, tom lane