public inbox for [email protected]help / color / mirror / Atom feed
Add <caution> for ALTER TEXT SEARCH CONFIGURATION 3+ messages / 3 participants [nested] [flat]
* Add <caution> for ALTER TEXT SEARCH CONFIGURATION @ 2019-11-15 19:09 Jeff Janes <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Jeff Janes @ 2019-11-15 19:09 UTC (permalink / raw) To: pgsql-docs If you alter one of the built-in text search configurations, the modifications to it will not get dumped by pg_dump, and thus won't get propagated by pg_upgrade leading to silent behavior changes in the new cluster (as well in any other type of restoration from pg_dump output) 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 until now of just how bad of an idea it was. I think that this needs to be warned about in the docs for ALTER TEXT SEARCH CONFIGURATION. If I were monkeying around in $SHAREDLIB/tsearch_data, I'd expect traps like this, but not when executing things from SQL after reading the docs on the command. Cheers, Jeff ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Add <caution> for ALTER TEXT SEARCH CONFIGURATION @ 2019-11-25 13:51 Euler Taveira <[email protected]> parent: Jeff Janes <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Euler Taveira @ 2019-11-25 13:51 UTC (permalink / raw) To: Jeff Janes <[email protected]>; +Cc: pgsql-docs Em sex., 15 de nov. de 2019 às 16:10, Jeff Janes <[email protected]> escreveu: > > If you alter one of the built-in text search configurations, the modifications to it will not get dumped by pg_dump, and thus won't get propagated by pg_upgrade leading to silent behavior changes in the new cluster (as well in any other type of 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 until now of just how bad of an idea it was. I think that this needs to be warned about in the docs for ALTER TEXT SEARCH CONFIGURATION. If I were monkeying around in $SHAREDLIB/tsearch_data, I'd expect traps like this, but not when executing things 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Add <caution> for ALTER TEXT SEARCH CONFIGURATION @ 2019-11-25 15:16 Tom Lane <[email protected]> parent: Euler Taveira <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Tom Lane @ 2019-11-25 15:16 UTC (permalink / raw) To: Euler Taveira <[email protected]>; +Cc: Jeff Janes <[email protected]>; pgsql-docs Euler Taveira <[email protected]> writes: > Em sex., 15 de nov. de 2019 às 16:10, Jeff Janes > <[email protected]> escreveu: >> If you alter one of the built-in text search configurations, the modifications to it will not get dumped by pg_dump, and thus won't get propagated by pg_upgrade leading to silent behavior changes in the new cluster (as well in any other type of restoration from pg_dump output) This isn't really different from what happens if you alter any object defined by initdb. (There are limited exceptions now for GRANT/REVOKE, but not for any other object property.) > It was a bad design to allow changes in builtin text search objects. I disagree. It is reasonable to point out that if you do that, propagating your changes to new databases is your problem. But the fact that you can mess with built-in objects has always been seen as a feature not a bug, and I'm not willing to change that approach, nor to start plastering random man pages with bright yellow cautions against doing so. Having the code itself issue complaints is right out. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2019-11-25 15:16 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2019-11-15 19:09 Add <caution> for ALTER TEXT SEARCH CONFIGURATION Jeff Janes <[email protected]> 2019-11-25 13:51 ` Euler Taveira <[email protected]> 2019-11-25 15:16 ` Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox