Subject: Re: Collation version tracking for macOS
Message-ID: <0867fe37-abbd-77ba-aafc-572074978bb0@amazon.com>
Date: Mon, 6 Jun 2022 19:10:37 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.9.0
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>
CC: Jeremy Schneider <schneider@ardentperf.com>, Peter Eisentraut
	<peter.eisentraut@enterprisedb.com>, pgsql-hackers
	<pgsql-hackers@postgresql.org>
References: <381977b1-0898-cb6f-a427-3b5d873e81bd@enterprisedb.com>
 <CA+hUKGKjkL=APm5nd3vGOtMAD_07nyvrbAaGaDduVD-EKM5Drw@mail.gmail.com>
 <ce1174ea-1942-37f0-421e-9ccff400dbcb@enterprisedb.com>
 <231072.1654273317@sss.pgh.pa.us>
 <1874de62-6bec-4bc1-1d14-0a2730b125da@ardentperf.com>
 <CA+hUKGLwT9xBSodtmio-NnGXfkrfVs02O6kg1iwBJSt-XMhW4g@mail.gmail.com>
 <366234.1654289888@sss.pgh.pa.us>
From: Jim Nasby <nasbyj@amazon.com>
In-Reply-To: <366234.1654289888@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/0867fe37-abbd-77ba-aafc-572074978bb0%40amazon.com>
Precedence: bulk

On 6/3/22 3:58 PM, Tom Lane wrote

> Thomas Munro <thomas.munro@gmail.com> writes:
>> On Sat, Jun 4, 2022 at 7:13 AM Jeremy Schneider
>> <schneider@ardentperf.com> wrote:
>>> It feels to me like we're still not really thinking clearly about this
>>> within the PG community, and that the seriousness of this issue is not
>>> fully understood.
>> FWIW A couple of us tried quite hard to make smarter warnings, and
>> that thread and others discussed a lot of those topics, like the
>> relevance to constraints and so forth.
> I think the real problem here is that the underlying software mostly
> doesn't take this issue seriously.  Unfortunately, that leads one to
> the conclusion that we need to maintain our own collation code and
> data (e.g., our own fork of ICU), and that isn't happening.  Unlike
> say Oracle, we do not have the manpower; nor do we want to bloat our
> code base that much.
>
> Short of maintaining our own fork, ranting about the imperfections
> of the situation is a waste of time.
The first step to a solution is admitting that the problem exists. 
Ignoring broken backups, segfaults and data corruption as a "rant" 
implies that we simply throw in the towel and tell users to suck it up 
or switch engines. There are other ways to address this short of the 
community doing all the work itself. One simple example would be to 
refuse to start if the collation provider has changed since initdb 
(which we'd need to allow users to override). A more sophisticated 
option would be to provide the machinery for supporting multiple 
collation libraries. Both of those at least ensure that users are aware 
any time there's a problem, which IMO is *enormously* better than 
letting core functionality silently stop working.