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 1mL6iD-0001wc-82 for pgsql-bugs@arkaria.postgresql.org; Tue, 31 Aug 2021 16:34:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mL6iA-0000gI-I6 for pgsql-bugs@arkaria.postgresql.org; Tue, 31 Aug 2021 16:34:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mL6iA-0000gA-Be for pgsql-bugs@lists.postgresql.org; Tue, 31 Aug 2021 16:34:10 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mL6i8-0004d6-49 for pgsql-bugs@lists.postgresql.org; Tue, 31 Aug 2021 16:34:09 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 17VGY5qs1689870; Tue, 31 Aug 2021 12:34:05 -0400 From: Tom Lane To: andrewbille@gmail.com cc: pgsql-bugs@lists.postgresql.org, Peter Eisentraut Subject: Re: BUG #17170: Invalid collation created with provider icu and initdb' locale C In-reply-to: <17170-95845cf3f0a9c36d@postgresql.org> References: <17170-95845cf3f0a9c36d@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Tue, 31 Aug 2021 07:15:54 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1689868.1630427645.1@sss.pgh.pa.us> Date: Tue, 31 Aug 2021 12:34:05 -0400 Message-ID: <1689869.1630427645@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > When using postgres built "--with-icu" I get an invalid collation with the > following script: > initdb -D db --locale=C > createdb testdb > psql testdb -c "CREATE COLLATION test (provider=icu, > locale='en_US.utf8');" > psql testdb -c "SELECT 'a' < 'b' COLLATE test;" > ERROR: collation "test" for encoding "SQL_ASCII" does not exist > LINE 1: SELECT 'a' < 'b' COLLATE test; > ^ That error doesn't seem inappropriate; ICU collations don't work in SQL_ASCII encoding. > psql testdb -c "DROP COLLATION test;" > ERROR: collation "test" for encoding "SQL_ASCII" does not exist That, however, is a bit annoying. If you can create the collation you should be able to drop it. The immediate issue is that DROP COLLATION uses the same lookup rule as other code paths, so it fails to see inapplicable pg_collation entries at all. So one approach to a fix is to relax its lookup rule. But I wonder if we should have prevented the CREATE in the first place, instead. Unfortunately, either approach is likely to still have some edge-case odd behaviors :-(. This whole business of having the database encoding be implicitly part of the lookup rule is just prone to that. regards, tom lane