Re: Add for ALTER TEXT SEARCH CONFIGURATION
От | Euler Taveira |
---|---|
Тема | Re: Add |
Дата | |
Msg-id | CAHE3wggE-k5y2Gnu45soTi5vJsJY12zqVZ_-VwNPHxtsUgFMrA@mail.gmail.com обсуждение исходный текст |
Ответ на |
Add |
Ответы |
Re: Add |
Список | pgsql-docs |
Em sex., 15 de nov. de 2019 às 16:10, Jeff Janes <jeff.janes@gmail.com> escreveu: > > If you alter one of the built-in text search configurations, the modifications to it will not get dumped by pg_dump, andthus won't get propagated by pg_upgrade leading to silent behavior changes in the new cluster (as well in any other typeof restoration from pg_dump output) > It was a bad design to allow changes in builtin text search objects. User expects that all modifications should be propagated while dumping a cluster. Since pg_ts_config_map does not have an oid column, it is not easy to guess that a text search configuration was modified (unless we dump the initial table and compare row-by-row). We could disallow changes in builtin text search objects but it could potentially break some scenarios. Even if it breaks a scenario, a workaround with another user-defined text search configuration is possible. > I would say it is bad practise to alter one of those anyway, rather than copy and alter the copy. But I wasn't aware untilnow of just how bad of an idea it was. I think that this needs to be warned about in the docs for ALTER TEXT SEARCHCONFIGURATION. If I were monkeying around in $SHAREDLIB/tsearch_data, I'd expect traps like this, but not when executingthings from SQL after reading the docs on the command. > Let's start with a tangible idea: add a big "caution" and also a WARNING while ALTER TEXT SEARCH CONFIGURATION whose schema is pg_catalog. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
В списке pgsql-docs по дате отправления: