Content-Type: multipart/alternative;
 boundary="------------TfuxM2hlp337x2elc0SNbILy"
Message-ID: <36f69fa9-db3f-44a1-8c8a-95ff09704a9c@postgresfriends.org>
Date: Tue, 17 Jun 2025 17:37:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Add CASEFOLD() function.
To: Jeff Davis <pgsql@j-davis.com>, Joe Conway <mail@joeconway.com>,
 Ian Lawrence Barwick <barwick@gmail.com>
Cc: pgsql-hackers@postgresql.org, Peter Eisentraut <peter@eisentraut.org>
References: <a1886ddfcd8f60cb3e905c93009b646b4cfb74c5.camel@j-davis.com>
 <CAB8KJ=jgnpbDTJS+jOQMzo7b1mPTwM0hCqQBBRgoX_kvyxWVog@mail.gmail.com>
 <ab1bdabcf64d799692ddaa5b06b5ef8afe94a0ef.camel@j-davis.com>
 <47716a78-eb0b-4728-8991-fc0d958a01c9@joeconway.com>
 <c3801da038f8f59ee63deb9104af1147d49454c8.camel@j-davis.com>
Content-Language: en-US
From: Vik Fearing <vik@postgresfriends.org>
In-Reply-To: <c3801da038f8f59ee63deb9104af1147d49454c8.camel@j-davis.com>
Archived-At: 
 <https://www.postgresql.org/message-id/36f69fa9-db3f-44a1-8c8a-95ff09704a9c%40postgresfriends.org>
Precedence: bulk

This is a multi-part message in MIME format.
--------------TfuxM2hlp337x2elc0SNbILy
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 16/12/2024 18:49, Jeff Davis wrote:
> One question I have is whether we want this function to normalize the
> output.


Yes, we do.


I am sorry that I am so late to the party, but I am currently writing 
the Change Proposal for the SQL Standard for this function.


For <fold> (which includes LOWER() and UPPER()), the text says in 
Section 6.35 GR 7.e:


If the character set of <character factor> is UTF8, UTF16, or UTF32, 
then FR is replaced by
     Case:
         i) If the <search condition> S IS NORMALIZED evaluates to True, 
then NORMALIZE (FR)
         ii) Otherwise, FR.


Here, FR is the result of the function and S is its argument.


It does not appear to me that our LOWER and UPPER functions obey this 
rule, so there is a valid argument that we should continue to ignore it. 
Or, we can say that we have at least one of three compliant.

-- 

Vik Fearing

--------------TfuxM2hlp337x2elc0SNbILy
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 16/12/2024 18:49, Jeff Davis wrote:<span
      style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
cite="mid:c3801da038f8f59ee63deb9104af1147d49454c8.camel@j-davis.com">
      <pre wrap="" class="moz-quote-pre">One question I have is whether we want this function to normalize the
output.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Yes, we do.</p>
    <p><br>
    </p>
    <p>I am sorry that I am so late to the party, but I am currently
      writing the Change Proposal for the SQL Standard for this
      function.</p>
    <p><br>
    </p>
    <p>For &lt;fold&gt; (which includes LOWER() and UPPER()), the text
      says in Section 6.35 GR 7.e:</p>
    <p><br>
    </p>
    <p>If the character set of &lt;character factor&gt; is UTF8, UTF16,
      or UTF32, then FR is replaced by<br>
          Case:<br>
              i) If the &lt;search condition&gt; S IS NORMALIZED
      evaluates to True, then NORMALIZE (FR)<br>
              ii) Otherwise, FR.</p>
    <p><br>
    </p>
    <p>Here, FR is the result of the function and S is its argument.</p>
    <p><br>
    </p>
    <p>It does not appear to me that our LOWER and UPPER functions obey
      this rule, so there is a valid argument that we should continue to
      ignore it. Or, we can say that we have at least one of three
      compliant.</p>
    <p>-- <br>
    </p>
    <p>Vik Fearing</p>
  </body>
</html>

--------------TfuxM2hlp337x2elc0SNbILy--