Subject: Re: Unicode normalization SQL functions
To: Daniel Verite <daniel@manitou-mail.org>
References: <6d55838c-9353-486f-a508-77ee07d59667@manitou-mail.org>
Cc: Andreas Karlsson <andreas@proxel.se>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <620b155b-a89c-d8e0-3cbb-315c3ca538f4@2ndquadrant.com>
Date: Tue, 24 Mar 2020 10:20:54 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <6d55838c-9353-486f-a508-77ee07d59667@manitou-mail.org>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2020-03-23 17:26, Daniel Verite wrote:
> 	Peter Eisentraut wrote:
> 
>> What is that status of this patch set?  I think we have nailed down the
>> behavior, but there were some concerns about certain performance
>> characteristics.  Do people feel that those are required to be addressed
>> in this cycle?
> 
> Not finding any other issue with v3 or objections in the thread,
> I've set the status to Ready For Committer in the CF.

I have committed the 0001 patch.

Now I have some concerns about the size of the new table in 
unicode_normprops_table.h, and the resulting binary size.  At the very 
least, we should probably make that #ifndef FRONTEND or something like 
that so libpq isn't bloated by it unnecessarily.  Perhaps there is a 
better format for that table?  Any ideas?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services