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

From Peter Eisentraut
Subject Re: Database-level collation version tracking
Date
Msg-id 2ffd4465-6550-290f-2a65-064481d90f16@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  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On 10.02.22 12:08, Julien Rouhaud wrote:
>> +                     errhint("Rebuild all objects affected by collation in the template database and run "
>> +                             "ALTER DATABASE %s REFRESH COLLATION VERSION, "
>> +                             "or build PostgreSQL with the right library version.",
>> +                             quote_identifier(dbtemplate))));
> 
> After a second read I think the messages are slightly ambiguous.  What do you
> think about specifying the problematic collation name and provider?
> 
> For now we only support libc default collation so users will probably have to
> reindex almost everything on that database (not sure if the versioning is more
> fine grained on Windows), but we should probably still specify "affected by
> libc collation" in the errhint so they have a chance to avoid unnecessary
> reindex.

I think accurate would be something like "objects using the default 
collation", since objects using a specific collation are not meant, even 
if they use the same provider.

>> +/*
>> + * ALTER DATABASE name REFRESH COLLATION VERSION
>> + */
>> +ObjectAddress
>> +AlterDatabaseRefreshColl(AlterDatabaseRefreshCollStmt *stmt)
> 
> 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.



pgsql-hackers by date:

Previous
From: Jeevan Ladhe
Date:
Subject: Re: refactoring basebackup.c
Next
From: Dipesh Pandit
Date:
Subject: Re: refactoring basebackup.c