Re: Database-level collation version tracking
От | Peter Eisentraut |
---|---|
Тема | Re: Database-level collation version tracking |
Дата | |
Msg-id | 2ffd4465-6550-290f-2a65-064481d90f16@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Database-level collation version tracking (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: Database-level collation version tracking
|
Список | 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 по дате отправления: