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.
