Re: [19] Proposal: function markers to indicate collation/ctype sensitivity

On 04.06.25 17:53, Jeff Davis wrote:
> On Wed, 2025-06-04 at 11:33 -0400, David E. Wheeler wrote:
>> I understand the need to trace these dependencies, but as a function
>> developer with relatively modest understanding of collation nuances,
>> I’m wondering how I’d know I needed these markers. It seems
>> complicated. Which leads me to think that adoption would be low
>> outside of core.
> 
> In the proposal, I mentioned adding runtime checks as future work.
> Perhaps that would be a requirement for this proposal so that users
> could get a warning? We could also make the markers negative, so that
> the default is to assume that a UDF with collatable inputs depends on
> all of the behaviors.

Yes, in my research in the past (see other message) I was also wondering 
about this.  One is, how do we get third-party code to update, the other 
is, how many functions, either in core or third-party, do you need to 
update, versus having a negative/opt-out approach.

My conclusion was also what you appear to be saying here:  We should 
assume by default that a function using a collatable data type might use 
the collation.  If the function doesn't, then the implementer can 
explicitly opt out.  This is similar to how functions are volatile by 
default, but implementers can mark them as stable or immutable as their 
own responsibility.