From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | s(dot)shinderuk(at)postgrespro(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17706: ALTER TYPE leads to crash |
Date: | 2022-12-13 02:58:30 |
Message-ID: | CAMbWs48eGK9YwbSprdwN4jWGeeC7xLLehb1ymFeZKFsTO9BmOg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Dec 8, 2022 at 1:01 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:
> We don't need to fix this though (i.e., make the query continue to somehow
> work), we need to detect the situation and return some kind of error as
> opposed to crashing the server. The transaction itself is doing something
> illegal and can be forced to abort. Alternatively, maybe the ALTER TYPE
> command can emit the error that it is unable to alter the type as it is
> already in use by the current session. But that would close off possible
> non-problematic uses of ALTER TYPE in this situation
>
Yeah, that makes sense. If we create a table using type foo, the alter
operation would error out like that.
create table t (a foo);
alter type foo alter attribute b type text;
ERROR: cannot alter type "foo" because column "t.a" uses it
Maybe we can likewise record the dependencies for the type if it's being
used in other more scenarios besides as a column in some table?
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2022-12-13 03:20:42 | Re: BUG #17713: Assert with postgres_fdw in v12 |
Previous Message | David Rowley | 2022-12-13 02:39:42 | Re: BUG #17710: Slow queries (100% CPU) after auto-vacuum |