Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iZElh-00050h-T9 for pgsql-docs@arkaria.postgresql.org; Mon, 25 Nov 2019 13:51:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iZElg-00065a-8T for pgsql-docs@arkaria.postgresql.org; Mon, 25 Nov 2019 13:51:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iZElf-00065T-TJ for pgsql-docs@lists.postgresql.org; Mon, 25 Nov 2019 13:51:08 +0000 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iZElY-00026y-2x for pgsql-docs@postgresql.org; Mon, 25 Nov 2019 13:51:07 +0000 Received: by mail-qt1-x842.google.com with SMTP id t20so17162508qtn.9 for ; Mon, 25 Nov 2019 05:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timbira-com-br.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qRs96mtvk4rihwnuVvOf8NB4f1TL5Mn76urPGgK2nv0=; b=eF7cpl3gHIjtpaAegehahHEFrmQp67KwCEnUrvcbFoGE2fTjVUJEOUvxvhqqo94tfF GhLobs3xJnOzQJfqCOEYkjwbZKKDOnC65nqJlCj+Pcf+tYdP7nS+oH1htyU4/l1wOeAR lQIFGzF1/GSPUpMJqAY5YI5AHvxd2h6INnpzKjOO7G0jUpWgmT7O6aDsv6Rcf8ukS/ms lFRnYCT/k0ujDEmubAXyhHD6EddKjrgG4sxzFo8pov24F6vAILij2Ha1llIj3764QZ+Q WmHyFR816v9+FonwgeIkddZUS28xH1t5B4UGeCuaIJaOr4KZR2mvYdU9ZxiDO/y+pE5x cSFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qRs96mtvk4rihwnuVvOf8NB4f1TL5Mn76urPGgK2nv0=; b=CWW1oE/KyHddXYI8tvsXpb594gtkZv5NbWWEaC5HHvy3j1eecwAIvDE2pb35b46UMv sKuoMt+/FDjzyBDsTbhnzAQE7yGpjOa6dozjeCfV28ps1ECg/gwU14Je5/9MTqwx4gt2 byBmCJSX9cOXnanprguPBBw5zWhL4PT25Pbauld00ZmDsn6ldeqxq7YX5UYPP1Lmxzs/ RHkJWh/yZ5rbTpOrcDvDun+i4vwg38IVEj0HLvhJ58UsfwnyTJUE9gyaBzf4uXR9IWZT c9mYImEKXsjRCo6XakEEZ2GJ2HeKuTG3HUYv0ZcDV4kI+tpJnBNbGemzDAmFC5mx5bT6 pnRg== X-Gm-Message-State: APjAAAW4dJfePqjz3v1k3L2+Gi++7VyifspUNH1NtuOtVxyIU/pqjhJz 208v1GEaXQmJe0ZtUB2UC7ZQsv8sLJNFkgfxOrNZRw== X-Google-Smtp-Source: APXvYqx+bHxCN+oanFWp7sOXTyEb72YeEm+mWyIooYESsiTIJKPXLeaZq1uAqMb4g23jikoCEtVEqtTeY4Cw4JWML9g= X-Received: by 2002:ac8:730d:: with SMTP id x13mr21885477qto.96.1574689856751; Mon, 25 Nov 2019 05:50:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Euler Taveira Date: Mon, 25 Nov 2019 10:51:23 -0300 Message-ID: Subject: Re: Add for ALTER TEXT SEARCH CONFIGURATION To: Jeff Janes Cc: pgsql-docs@postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Em sex., 15 de nov. de 2019 =C3=A0s 16:10, Jeff Janes escreveu: > > If you alter one of the built-in text search configurations, the modifica= tions to it will not get dumped by pg_dump, and thus won't get propagated b= y 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 a= n 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 fro= m 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. --=20 Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento