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 1nKN12-0000yj-I7 for pgsql-docs@arkaria.postgresql.org; Wed, 16 Feb 2022 16:18:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nKN11-0000V0-BI for pgsql-docs@arkaria.postgresql.org; Wed, 16 Feb 2022 16:18:51 +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 1nKN11-0000Ur-3r for pgsql-docs@lists.postgresql.org; Wed, 16 Feb 2022 16:18:51 +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 1nKN0y-0000Dd-QH for pgsql-docs@lists.postgresql.org; Wed, 16 Feb 2022 16:18:50 +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 21GGIkph3324022; Wed, 16 Feb 2022 11:18:46 -0500 From: Tom Lane To: "David G. Johnston" cc: pageorge@unice.fr, Pg Docs Subject: Re: Does the POSITION() function takes into account the COLLATION... or not ?!? In-reply-to: References: <164494187300.23318.373331246819207718@wrigleys.postgresql.org> Comments: In-reply-to "David G. Johnston" message dated "Wed, 16 Feb 2022 09:10:08 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3324020.1645028326.1@sss.pgh.pa.us> Date: Wed, 16 Feb 2022 11:18:46 -0500 Message-ID: <3324021.1645028326@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Tue, Feb 15, 2022 at 11:17 AM PG Doc comments form < > noreply@postgresql.org> wrote: >> ==> up to here, this seems pretty enough to conclude that POSITION() >> doesn't >> care at all about COLLATION and always perform a byte search. > How collations behave is documented, in particular: > "A collation is either deterministic or nondeterministic. A deterministic > collation uses deterministic comparisons, which means that it considers > strings to be equal only if they consist of the same byte sequence." Right. POSITION does indeed do bytewise search, which is a legal implementation for any deterministic collation, but perhaps not for a nondeterministic one. Thus, it throws a feature-not-supported error if asked to use a nondeterministic collation. As you say, this is far from the only function that acts that way. regards, tom lane