Re: BUG #18310: Some SQL commands fail to process duplicate objects with error: tuple already updated by self
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tender Wang <tndrwang@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2024-01-28T23:34:02Z
Lists: pgsql-bugs
On Fri, Jan 26, 2024 at 11:23:08AM +0800, Tender Wang wrote: > Michael Paquier <michael@paquier.xyz> 于2024年1月26日周五 10:51写道: >> For this job, I think user.c is just overengineered and could be >> simplified to use a list of OIDs. There is no need for ObjectAddress >> or even ObjectAddresses: all of them are created with >> AuthIdRelationId as class ID, and the second loop just fetches the >> role IDs retrieved from the ObjectAddresses created in the first loop. >> We don't use the individual ObjectAddress either. On top of all that, >> it makes the code a bit easier to follow. > > Agreed. +1 Thanks, I've applied this one down v16 as of 50b797dc99ec. v15 and older do not use a two-pass logic in DropRole() so one would fail with a simpler "role does not exist", which is kind of correct in its own way because the second role cannot be scanned in pg_authid after the CCI of the first one, so I have let it be in older versions. It's not like somebody complained about that in the past, either, as far as I recall. -- Michael
Commits
-
Fix various issues with ALTER TEXT SEARCH CONFIGURATION
- 0561097822a1 12.18 landed
- 4d0e8a008bdc 13.14 landed
- dde5b01c33f9 14.11 landed
- 41fa4b31c12f 15.6 landed
- f33e83285a14 16.2 landed
- 3e91dba8b079 17.0 landed
-
Fix DROP ROLE when specifying duplicated roles
- f57a580fd280 16.2 landed
- 50b797dc99ec 17.0 landed