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 1nKNXU-0002ao-DQ for pgsql-docs@arkaria.postgresql.org; Wed, 16 Feb 2022 16:52:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nKNXT-0003sL-DE for pgsql-docs@arkaria.postgresql.org; Wed, 16 Feb 2022 16:52:23 +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 1nKI3q-00016p-05 for pgsql-docs@lists.postgresql.org; Wed, 16 Feb 2022 11:01:26 +0000 Received: from ip-nice01.unice.fr ([134.59.1.214]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nKI3k-0006XF-J1 for pgsql-docs@lists.postgresql.org; Wed, 16 Feb 2022 11:01:25 +0000 IronPort-SDR: g3leQ1WcjFjgD3fh97qQi0DYxe1/k7EPfhD5Nz893L4rFcp7296vwKAYVTXWfOO1qZ8ODdaqUF /liXCe8Pg/aA== IronPort-Data: =?us-ascii?q?A9a23=3A2T4bWaPjI2Dc7PHvrR1UlcFynXyQoLVcMsEvi?= =?us-ascii?q?/4bfWQNrUom32RVx2RNWDyGP/qJMDf2LowiaITl90MH7MPTmtViTVdlrnsFo?= =?us-ascii?q?1CmCCbm6XZ1Fqp6Vs+rBpWroHlPsoNOOrEsEOhuFiWG/k31a+C4xZVB/frgq?= =?us-ascii?q?oTUWbas1h9ZGFcMpBcJ0XqPqsZh6mJaqYHR7zCl5bsel/bi1GqNgFaYBI61B?= =?us-ascii?q?5Wr83uDtNyq0N8RU8dXifpj5DcynFFNZH4TyD3Yw9IVn+Bp8uCGq+brlNlV/?= =?us-ascii?q?0vf9gcqEYnjj7D6eUBMTKS60Qqm0yEKHfXzxEEE/3Vouko4HKN0hUN/szSEh?= =?us-ascii?q?cp8jfxQr5G0SAoveILhv94yfiJwDid/I+hN/6PKLXGtrNbVwVeun37Enag3U?= =?us-ascii?q?xFmYdNIkgpwKSQUnRACExgVYQuag6e6x7mgYu1tndg4atHsJ58QoHx71DWfC?= =?us-ascii?q?uwpKbjbSqrH4sVX0R82j9BJBq+YeswYYjcpYg6oSwVCJloNTp8/h+qummP2b?= =?us-ascii?q?iFwpVSJqLAv+WnIwQB7lrPqNbLolnaiLSlOtkCRtmXdpSLkBBAROZqR01K4H?= =?us-ascii?q?ruXrrentUvGtEg6SdVULsJXvWA=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AnIxrUqiY95XL4zNHPOIvF4SDVnBQXtcji2?= =?us-ascii?q?hC6mlwRA09TyXqraGTdZMgpHjJYVcqKRUdcL+7VZVoLUmsl6KdpLNhWItKPz?= =?us-ascii?q?OLhILLFutfBOLZqlWKJ8S9zJ8/6U4KScZD4bPLbWSSwfyU3DWF?= X-IronPort-AV: E=Sophos;i="5.88,333,1635199200"; d="scan'208";a="651788468" Received: from naxos2.unice.fr ([134.59.1.112]) by ip-nice08.unice.fr with ESMTP; 16 Feb 2022 12:01:19 +0100 Received: from [192.168.0.10] (hau60-1_migr-88-127-28-178.fbx.proxad.net [88.127.28.178] (may be forged)) (authenticated bits=0) by naxos2.unice.fr (8.14.7/8.14.7) with ESMTP id 21GB1IUj035675 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Feb 2022 12:01:19 +0100 Message-ID: Date: Wed, 16 Feb 2022 12:01:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: Does the POSITION() function takes into account the COLLATION... or not ?!? Content-Language: en-GB To: Peter Eisentraut , pageorge@unice.fr, pgsql-docs@lists.postgresql.org References: <164494187300.23318.373331246819207718@wrigleys.postgresql.org> <08bff51d-eb6b-381f-ca6b-08234828c754@enterprisedb.com> From: =?UTF-8?Q?Pierre-Aur=c3=a9lien_GEORGES?= In-Reply-To: <08bff51d-eb6b-381f-ca6b-08234828c754@enterprisedb.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ok, let's take it forwards, then :-) Can someone provide some examples where a supported deterministic collation is having an impact on the result of a call to function POSITION() ? (as I said in my message, examples would be greatly appreciated) Le 16/02/2022 à 11:56, Peter Eisentraut a écrit : > On 15.02.22 17:17, PG Doc comments form wrote: >> Does the POSITION() function pretends taking into account the >> COLLATION ?? >> or not ?? >> >> - If not, then why the hell is there this error message about >> nondeterministic collations while the POSITION() doesn't care at all >> about >> the COLLATION... >> - If yes, then the first 6 lines of SQL above are returning the wrong >> value... (are there any specific technical limitations here ?) > > I think you have that backwards.  Your examples would only succeed if > POSITION() supported nondeterministic collations, but it doesn't.