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

Hi Jeff,

On Jun 3, 2025, at 23:22, Jeff Davis <pgsql@j-davis.com> wrote:

> If we didn't have separate markers, we'd need to assume that all of
> those objects could be affected by a provider update.

I understand the need to trace these dependencies, but as a function developer with relatively modest understanding of
collationnuances, I’m wondering how I’d know I needed these markers. It seems complicated. Which leads me to think that
adoptionwould be low outside of core. 

Best,

David

On Wed, Jun 4, 2025 at 8:34 AM David E. Wheeler <david@justatheory.com> wrote:
> On Jun 3, 2025, at 23:22, Jeff Davis <pgsql@j-davis.com> wrote:
>
> > If we didn't have separate markers, we'd need to assume that all of
> > those objects could be affected by a provider update.
>
> I understand the need to trace these dependencies, but as a function developer with relatively modest understanding
ofcollation nuances, I’m wondering how I’d know I needed these markers. It seems complicated. Which leads me to think
thatadoption would be low outside of core. 

That was my first thought as well. But my second thought was: does
that matter? There are substantial benefits to having this for just
core functions, no?

Thanks,
Maciek

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.

Regards,
    Jeff Davis

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.