Re: Internal error with types changes and prepared statements
От | Tom Lane |
---|---|
Тема | Re: Internal error with types changes and prepared statements |
Дата | |
Msg-id | 2220999.1632335261@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Internal error with types changes and prepared statements (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: Internal error with types changes and prepared statements
Re: Internal error with types changes and prepared statements |
Список | pgsql-bugs |
Daniele Varrazzo <daniele.varrazzo@gmail.com> 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
В списке pgsql-bugs по дате отправления: