Thread: Re: Collation & ctype method table, and extension hooks

Re: Collation & ctype method table, and extension hooks

From
Andreas Karlsson
Date:
On 9/27/24 12:30 AM, Jeff Davis wrote:
> The attached patch series refactors the collation and ctype behavior
> into method tables, and provides a way to hook the creation of a
> pg_locale_t so that an extension can create any kind of method table it
> wants.

Great! I had been planning to do this myself so great to see that you 
already did it before me. Will take a look at this work later.

Andreas




Re: Collation & ctype method table, and extension hooks

From
Jeff Davis
Date:
On Fri, 2024-10-04 at 15:24 +0200, Andreas Karlsson wrote:
> Great! I had been planning to do this myself so great to see that you
> already did it before me. Will take a look at this work later.

Great! We'll need to test whether there are any regressions in the
regex & pattern matching code due to the indirection.

What would be a good test for that? Just running it over long strings?

Regards,
    Jeff Davis




Re: Collation & ctype method table, and extension hooks

From
Peter Eisentraut
Date:
On 12.06.25 07:49, Jeff Davis wrote:
> On Fri, 2025-02-07 at 11:19 -0800, Jeff Davis wrote:
>>
>> Attached v15. Just a rebase.
> 
> Attached v16.
> 
>> * commit this on the grounds that it's a desirable code improvement
>> and
>> the worst-case regression isn't a major concern; or
> 
> I plan to commit this soon after branching. There's a general consensus
> that enabling multi-lib provider support is a good idea, and turning
> the provider behavior into method tables is a prerequisite for that. I
> doubt the performance issue will be a serious concern and I don't see a
> good way to avoid it.

Patch 0001 and 0002 seem okay to me.

I wish we could take this further and also run the "ctype is c" case 
through the method table.  Right now, there are still a bunch of 
open-coded special cases all over the place, which could be unified.  I 
guess this isn't any worse than before, but maybe this could be a future 
project?

Patch 0003 I don't understand.  It replaces type safety by no type 
safety, and it doesn't have any explanation or comments.  I suppose you 
have further plans in this direction, but until we have seen those and 
have more clarification and explanation, I would hold this back.

Patch 0004 seems ok.  But maybe you could explain this better in the 
commit message, like remove includes from pg_locale.h but instead put 
them in the .c files as needed, and explain why this is possible or 
suitable now.