Re: BUG #16703: pg-dump fails to process recursive view definition
От | Tom Lane |
---|---|
Тема | Re: BUG #16703: pg-dump fails to process recursive view definition |
Дата | |
Msg-id | 1438431.1604588428@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #16703: pg-dump fails to process recursive view definition (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #16703: pg-dump fails to process recursive view definition
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > The following recursive views (borrowed from regress/sql/lock.sql, see > "detecting infinite recursions in view definitions"): > CREATE VIEW lock_view2(a) AS SELECT NULL::integer; > CREATE VIEW lock_view3 AS SELECT * from lock_view2; > CREATE OR REPLACE VIEW lock_view2 AS SELECT * from lock_view3; > can be created successfully, but make a subsequent pg_dump fail: > pg_dump: error: query failed: ERROR: infinite recursion detected in rules > for relation "lock_view2" > pg_dump: error: query was: LOCK TABLE public.lock_view2 IN ACCESS SHARE > MODE > The offending commit is 64fc3e03. Yeah, not surprising. It seems like the least painful solution might be to teach LockTableRecurse to detect recursion and just not recurse into a view it's already locked. (BTW, I wonder if we shouldn't have a stack depth check there, too.) regards, tom lane
В списке pgsql-bugs по дате отправления: