Re: BUG #18892: When the view already exists, CREATE OR REPLACE VIEW does not check whether the table exists.
От | Tom Lane |
---|---|
Тема | Re: BUG #18892: When the view already exists, CREATE OR REPLACE VIEW does not check whether the table exists. |
Дата | |
Msg-id | 828700.1744553105@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18892: When the view already exists, CREATE OR REPLACE VIEW does not check whether the table exists. (Kirill Reshke <reshkekirill@gmail.com>) |
Список | pgsql-bugs |
Kirill Reshke <reshkekirill@gmail.com> writes: > On Sun, 13 Apr 2025 at 00:33, David G. Johnston > <david.g.johnston@gmail.com> wrote: >> Kirill's answer is correct; though it is a bit annoying that "create view" cannot detect the infinite recursion inherentin its body. > Hm, if we can detect infinite recursion at runtime, we should also be > able to do it definition-time, on "create or replace". Is there any > reason we omit such a check (for recursive views/relations) when > executing ddl? I don't think this would be an improvement, because it would cause errors that need not happen. For example, if the recursion is through two views, then altering either one might be enough to remove the problem. Refusing to create the second view is pre-judging where the problem lies. And it's not like the run-time error is obscure. I think this suggestion is much like the one we recently rejected about throwing an error if the user tries to attach a default to a view column whose underlying column is generated. In short: "if you were to try to execute this right now, it would fail" is not a great argument for refusing to create an object whose behavior is intertwined with other objects. regards, tom lane
В списке pgsql-bugs по дате отправления: