Re: Database-level collation version tracking

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Database-level collation version tracking
Date: 2022-02-14 08:55:19
Message-ID: 5624aba8-7e71-3a44-3905-f3c0837e7eff@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-02-14 09:00:27 Collation version tracking for macOS
Previous Message Kyotaro Horiguchi 2022-02-14 08:14:28 Re: Assertion failure in WaitForWALToBecomeAvailable state machine