Re: BUG #16703: pg-dump fails to process recursive view definition - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #16703: pg-dump fails to process recursive view definition
Date
Msg-id 1438431.1604588428@sss.pgh.pa.us
Whole thread Raw
In response to BUG #16703: pg-dump fails to process recursive view definition  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #16703: pg-dump fails to process recursive view definition
List 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 by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: BUG #16702: inline code and function : when use dynamic name for rowtype, there is some bug!
Next
From: Wolfgang Walther
Date:
Subject: Re: Wrong result for comparing ROW(...) with IS NOT NULL