Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rooVL-003WWS-FA for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Mar 2024 17:53:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rooVJ-006M32-T6 for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Mar 2024 17:53:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rooVJ-006M2t-FI for pgsql-hackers@lists.postgresql.org; Mon, 25 Mar 2024 17:53:02 +0000 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rooVG-006NH8-3S for pgsql-hackers@postgresql.org; Mon, 25 Mar 2024 17:53:00 +0000 Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6e740fff1d8so3215550b3a.1 for ; Mon, 25 Mar 2024 10:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20230601.gappssmtp.com; s=20230601; t=1711389178; x=1711993978; darn=postgresql.org; 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=u/AojteCgfbeNvT/Xk6bii0Id5MhEuV6o8NvjJu/q0o=; b=c2955E6ufTmsjBa+2DapLCpMzr+xj91f16pbPe1btsXg7g+mH+3uZJH3orTCsh2H6s 5PJh0/Dcopj2GjlBoLm3aLYKlQxWLgUxqkF7l3NcEmSF3hE1qubDCLd1Uc30BqyFRfO7 PH8Zlr7zEAlzPxPFUK6xRMrY1KoZaqwxVklPbHFJ6iwJhPU7WPDOJSViWHqZOLaZL9rw 2lPCHexjxlDshyWBlW5jjvVP6vQU0G8kaCzPDrICdWjOYG4MYVlV4btzegF7pKF/50ly kelc7pTHXqeznAsa8TExHWsMLUxzpR0YQzz10bwSvTSdlMSzyvyz8YG53eYXb9OplxDq v0Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711389178; x=1711993978; 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=u/AojteCgfbeNvT/Xk6bii0Id5MhEuV6o8NvjJu/q0o=; b=nKO3tOfko7af15Wrb7X7yGXyFSn5L5n4fe5DpViqjUbWUQdVvqRaKck7B3DEycSCUj PzHRl6hrGtraoocO3g3NOM+MzEenFgkar/k2IfzVdqQwNqZ1ap2CbfnkUy6G1VRmC8aJ b59HzLuiw53iNs5RgN7ZYN5cHO6sm3s5Vph1cN5C4UKUlbKL3pR6MA52ETklkCrUVRQN ZN+65Jj4ny9VxS4w/eTDF+MCGA7q+kcJs8u9nv99aid9PeN6CCsvd/90i8zj0wGWtZxj 2LGtFEmZeLXhLuaY9VZXfw+B4AsUvsae3Nu6+Z4QUB/g3qlMDPkAsfbV6uANNmwrNz/2 IYQw== X-Forwarded-Encrypted: i=1; AJvYcCVDIO16dVKTvEi5WDeBkp0xu27neUgiTGyzm8wsZyj5MGXwAU9wvHjgW7pR3z8nS6v6pnsWvCH3ZQrMjTbGmGFVUgSKkMFrWujlXNz2 X-Gm-Message-State: AOJu0YwrE2xcADiqIpf9uYNMRjFrZLGuPJj871AFdA82Omeq7sva7HNp PBfJ7OHfTBJdK59LQC4t8I1W+Y4L08lKTGaSzXGd36MnGxYHMCu2jTiDGmbDZQ== X-Google-Smtp-Source: AGHT+IF8gv5Ou3LyaSpjRJozLiz5s6ErMZHzi+VKCpm4+z1ymtasfrQN9yLsRb/UYJZVO0zAOoXC7w== X-Received: by 2002:a05:6a00:2e29:b0:6ea:b1f5:112c with SMTP id fc41-20020a056a002e2900b006eab1f5112cmr2071657pfb.27.1711389177768; Mon, 25 Mar 2024 10:52:57 -0700 (PDT) Received: from jeff-laptop.lan (c-76-102-242-158.hsd1.ca.comcast.net. [76.102.242.158]) by smtp.gmail.com with ESMTPSA id e12-20020aa7824c000000b006e5f754646csm4363134pfn.139.2024.03.25.10.52.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 10:52:57 -0700 (PDT) Message-ID: <1466f20c38f4433c98a950acdaf2c96daf7ce442.camel@j-davis.com> Subject: Re: Built-in CTYPE provider From: Jeff Davis To: Peter Eisentraut , Daniel Verite Cc: Robert Haas , Jeremy Schneider , pgsql-hackers@postgresql.org Date: Mon, 25 Mar 2024 10:52:56 -0700 In-Reply-To: <4c9eea58-08a1-4629-a004-439e2cf12de8@eisentraut.org> References: <6f3e94c0-f174-4380-9b69-072f8a838881@manitou-mail.org> <2692039df6b0cac20c5e488fa0209e8958c5fedb.camel@j-davis.com> <27bb0e52-801d-4f73-a0a4-02cfdd4a9ada@eisentraut.org> <4a69d067374d2f6bfb66f5bfb2ab9a020493d49f.camel@j-davis.com> <3bc653b5d562ae9e2838b11cb696816c328a489a.camel@j-davis.com> <163f4e2190cdf67f67016044e503c5004547e5a9.camel@j-davis.com> <6bdb98e68b2b05aa71f7f934e227738eac84ecee.camel@j-davis.com> <19b34a70-f5cf-4faf-88dc-917db44ed48d@eisentraut.org> <846a7e1fa2024918b58ff7583523a2f3de9a11b4.camel@j-davis.com> <3117d30aa911b408b90420f4f280fa0c3b5851be.camel@j-davis.com> <4135cf11-206d-40ed-96c0-9363c1232379@eisentraut.org> <7451f81ba0cb512222ab759de8ca1cffe44e9acb.camel@j-davis.com> <1f309153-8198-4efa-86dd-8c304ec0040c@eisentraut.org> <49f18979-bef5-4cf0-bf3d-8a5ed323f470@eisentraut.org> <69f832595838e40c1b071a5e750665190ba301bf.camel@j-davis.com> <4c9eea58-08a1-4629-a004-439e2cf12de8@eisentraut.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2024-03-25 at 08:29 +0100, Peter Eisentraut wrote: > Right.=C2=A0 I thought when you said there is an ICU configuration for it= , > that it might be like collation options that you specify in the > locale=20 > string.=C2=A0 But it appears it is only an internal API setting.=C2=A0 So= that, > in=20 > my mind, reinforces the opinion that we should leave initcap() as is > and=20 > make a new function that exposes the new functionality.=C2=A0 (This does > not=20 > have to be part of this patch set.) OK, I'll propose a "title" or "titlecase" function for 18, along with "casefold" (which I was already planning to propose). What do you think about UPPER/LOWER and full case mapping? Should there be extra arguments for full vs simple case mapping, or should it come from the collation? It makes sense that the "dotted vs dotless i" behavior comes from the collation because that depends on locale. But full-vs-simple case mapping is not really a locale question. For instance: select lower('0=CE=A3' collate "en-US-x-icu") AS lower_sigma, lower('=CE=91=CE=A3' collate "en-US-x-icu") AS lower_final_sigma, upper('=C3=9F' collate "en-US-x-icu") AS upper_eszett; lower_sigma | lower_final_sigma | upper_eszett=20 -------------+-------------------+-------------- 0=CF=83 | =CE=B1=CF=82 | SS produces the same results for any ICU collation. There's also another reason to consider it an argument rather than a collation property, which is that it might be dependent on some other field in a row. I could imagine someone wanting to do: SELECT UPPER(some_field, full =3D> true, dotless_i =3D> CASE other_field WHEN ...) FROM ... That makes sense for a function in the target list, because different customers might be from different locales and therefore want different treatment of the dotted-vs-dotless-i. Thoughts? Should we use the collation by default but then allow parameters to override? Or should we just consider this a new set of functions? (All of this is v18 material, of course.) Regards, Jeff Davis