From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | exclusion(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: BUG #16703: pg-dump fails to process recursive view definition |
Date: | 2020-11-05 15:00:28 |
Message-ID: | 1438431.1604588428@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Wolfgang Walther | 2020-11-05 15:06:01 | Re: Wrong result for comparing ROW(...) with IS NOT NULL |
Previous Message | David G. Johnston | 2020-11-05 14:15:45 | Re: BUG #16702: inline code and function : when use dynamic name for rowtype, there is some bug! |