Re: Database-level collation version tracking - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Database-level collation version tracking
Date
Msg-id 5624aba8-7e71-3a44-3905-f3c0837e7eff@enterprisedb.com
Whole thread Raw
In response to Re: Database-level collation version tracking  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Database-level collation version tracking
Re: Database-level collation version tracking
List pgsql-hackers
On 11.02.22 13:51, Julien Rouhaud wrote:
>>> I'm wondering why you changed this function to return an ObjectAddress rather
>>> than an Oid?  There's no event trigger support for ALTER DATABASE, and the rest
>>> of similar utility commands also returns Oid.
>>
>> Hmm, I was looking at RenameDatabase() and AlterDatabaseOwner(), which
>> return ObjectAddress.
> 
> Apparently I managed to only check AlterDatabase and AlterDatabaseSet, which
> both return an Oid.  Maybe we could also update those two to also return an
> ObjectAddress, for consistency?

I have committed this patch.

I didn't address the above issue.  I looked at it a bit, but I also 
found other (non-database) object types that had a mix of different 
return types.  It's not clear to me what this is all supposed to mean. 
If no one is checking the return, they should really all be turned into 
void, IMO.  Maybe this should be a separate discussion.



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Assertion failure in WaitForWALToBecomeAvailable state machine
Next
From: Peter Eisentraut
Date:
Subject: Collation version tracking for macOS