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 | 5b7bfc39726ff9f6c52dd73e337c34e74e0d1f39 (patch) | |
| tree | 26bacc8d4af4da76765675e0e1a74ba238235a26 /src/backend/commands/dbcommands.c | |
| parent | 48e1291342dd7771cf8c67aa1d7ec1f394b95dd8 (diff) | |
| download | postgresql-5b7bfc39726ff9f6c52dd73e337c34e74e0d1f39.tar.gz postgresql-5b7bfc39726ff9f6c52dd73e337c34e74e0d1f39.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/commands/dbcommands.c')
0 files changed, 0 insertions, 0 deletions