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.
