diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-11-05 11:44:32 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-11-05 11:44:32 -0500 |
| commit | 44b973b91029cb5aecf09d589bdf3f05cfddaa60 (patch) | |
| tree | fa216a3dad59fe5048bc373f548baee8b3936ff0 /src/backend/executor/nodeModifyTable.c | |
| parent | 02c9386ca4f706364904be2720e2d09916e2b619 (diff) | |
| download | postgresql-44b973b91029cb5aecf09d589bdf3f05cfddaa60.tar.gz postgresql-44b973b91029cb5aecf09d589bdf3f05cfddaa60.zip | |
Don't throw an error for LOCK TABLE on a self-referential view.
LOCK TABLE has complained about "infinite recursion" when applied
to a self-referential view, ever since we made it recurse into views
in v11. However, that breaks pg_dump's new assumption that it's
okay to lock every relation. There doesn't seem to be any good
reason to throw an error: if we just abandon the recursion, we've
still satisfied the requirement of locking every referenced relation.
Per bug #16703 from Andrew Bille (via Alexander Lakhin).
Discussion: https://postgr.es/m/16703-e348f58aab3cf6cc@postgresql.org
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions