Re: Collation & ctype method table, and extension hooks

On Fri, 2024-10-04 at 15:24 +0200, Andreas Karlsson wrote:
> 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.

Attached v6 with significant improvements, and should be easier to
review.

This removes all runtime branching for collation & ctype operations; I
even removed the "provider" field of pg_locale_t to be sure.

This series gets us to the point where it's possible (though not easy)
to completely replace the provider at runtime without missing any
capabilities.

There are many things that would be nice to improve further, such as:

* Have a CREATE LOCALE PROVIDER command and make "provider" an Oid
rather than a char ('b'/'i'/'c'). The v6 patches brings us close to
this point, but I'm not sure if we want to go this far in v18.

* Need an actual extension to prove that it works.

* Clean up the way versions are handled.

* Do we want to provide support for changing the provider at initdb
time?

* The catalog representation is not very clean or general. The libc
provider allows collation and ctype to be set separately, but they
control the environment variables, too. ICU has rules, which are
specific to ICU.

* I've tested the performance for collation and case mapping, and there
does not appear to be any overhead. I didn't observe any performance
overhead for ctype either, but I think I need a more strenuous test to
be sure.

Regards,
Jeff Davis