Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pxGcu-00020F-Lz for pgsql-bugs@arkaria.postgresql.org; Fri, 12 May 2023 00:27:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pxGct-0002FE-DB for pgsql-bugs@arkaria.postgresql.org; Fri, 12 May 2023 00:27:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pxGct-0002F5-1O for pgsql-bugs@lists.postgresql.org; Fri, 12 May 2023 00:27:15 +0000 Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pxGcl-0024z6-TM for pgsql-bugs@postgresql.org; Fri, 12 May 2023 00:27:14 +0000 Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-64388cf3263so6661398b3a.3 for ; Thu, 11 May 2023 17:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20221208.gappssmtp.com; s=20221208; t=1683851226; x=1686443226; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=Bd8Tl6rdsrNiCkDIQ1IvbMmNVKmUamFsYJMXdhnbYhs=; b=2NpNs5We61OBProSaYKc4fMVkHmGnwfG+DvIpeR5XqYUMflt6evdSt6KNy+i1FHYFs 8PJX6W9upeEYqA4gi/0eqYqOFfWmoAefYnhQebjNXOKfn5y+Z9fN5c1XgqufkMl6nCgN 8yBz7UAE2lMkzowIuNaEaPPqzxVV5D8xdswKpFWYtb6pSZ9UZ+1UywNX5hlKhqSY0DNw ZZN/8okXI3Pvhcx3mZ5D+NknNWhUbleEv9kN+xXzyAeWR/CeTvpvbsOeA56S8aPX0Xrb hakGmdHYW/MSdMfTBRzIGxH+RtJlp1PtlRuxcNEjEVn2zitkkC7v3joosuVhbF4/yJkN gyfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683851226; x=1686443226; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Bd8Tl6rdsrNiCkDIQ1IvbMmNVKmUamFsYJMXdhnbYhs=; b=UmquqRIlky24777VNNiaSRJx5D2vezslnVc9GgHPHSI7jryVXB5zNu9RdZ5RBR9WT7 hMMmTXI04zHc4RQPG4qA1APyy6sCFKmKO6eo6MbpGqI2gEQ+8PRNTQ8taBWBFzDybnhO bcYGaSKfSkkNC6xJPI5075uCm9k3v4X5TtDFRwDTT/pvX0mYybYHqAkWy65/wzrfzoLz y1cEsUyUBmu5sNu5xOD043/NGUg0uPOKqVBp7hW/Nth1EZ23Pya/KbwfjlOj92IXNntG pkmFoLgXXepylLbliV5ELRy1+LgkuGSHbWF2TfUS+FbajU/lrWoUrQiiisb7Mt4aOTvf Qk2w== X-Gm-Message-State: AC+VfDwWwq3RjaEKEC81kVpZ14wdA3S4cp7IsMJ3BqACVs6Hon0Q4v1E aFzAxjXSMVE0mwSuQ+9n7ouC9w== X-Google-Smtp-Source: ACHHUZ7Hpj6AsBVTlwEZwbf2xAixgC47fAzu+hg9VaFNJroCseskHIE2NNVa4s3XD7eYkck61h/ThA== X-Received: by 2002:a05:6a00:b8a:b0:646:663a:9d60 with SMTP id g10-20020a056a000b8a00b00646663a9d60mr21441901pfj.10.1683851225939; Thu, 11 May 2023 17:27:05 -0700 (PDT) Received: from jeff-laptop.lan (c-73-170-46-202.hsd1.ca.comcast.net. [73.170.46.202]) by smtp.gmail.com with ESMTPSA id n18-20020a62e512000000b0062dcf5c01f9sm5883738pff.36.2023.05.11.17.27.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 May 2023 17:27:05 -0700 (PDT) Message-ID: Subject: Re: Possible to create a hidden collation From: Jeff Davis To: Tom Lane Cc: pgsql-bugs@postgresql.org Date: Thu, 11 May 2023 17:27:04 -0700 In-Reply-To: <1209303.1683849734@sss.pgh.pa.us> References: <051c9395cf880307865ee8b17acdbf7f838c1e39.camel@j-davis.com> <1209303.1683849734@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2023-05-11 at 20:02 -0400, Tom Lane wrote: > What happens if somebody makes a user-defined collation in template0 > and then clones that into a different encoding? I didn't know changing template0 was supported behavior for normal operation. > =C2=A0 I guess the user-defined > collation would then be hidden/inaccessible in the clone DB, so maybe > it's > fine. Assuming we do support changes to template0, the fix would prevent users from making a new ICU collation in template0 that is visible to all encodings, other than calling pg_import_system_collations(). That doesn't sound like a big problem; it's already impossible to do that with libc collations. Regards, Jeff Davis