Horton

Re: Collation & ctype method table, and extension hooks

Jeff Davis <pgsql@j-davis.com>

View thread View on postgr.es
From: Jeff Davis <pgsql@j-davis.com>
To: Andreas Karlsson <andreas@proxel.se>, pgsql-hackers@postgresql.org, Peter Eisentraut <peter@eisentraut.org>
Date: 2025-02-07T19:19:21Z
Lists: pgsql-hackers

Attachments

> I'm still inlined to think the method table is a good thing to do:
> 
> (a) The performance cases I tried seem implausibly bad -- running
> character classification patterns over large fields consisting only
> of
> codepoints over U+07FF.
> 
> (b) The method tables seem like a better code organization that
> separates the responsibilities of the provider from the calling code.
> It's also a requirement (or nearly so) if we want to provide some
> pluggability or support multiple library versions.
> 
> It would be good to hear from others on these points, though.

Attached v15. Just a rebase.

I'd still like some input here. We could either:

* commit this on the grounds that it's a desirable code improvement and
the worst-case regression isn't a major concern; or

* wait until v19 when we might have a more compelling use for the
method table (e.g. pluggable provider or multilib)

Regards,
	Jeff Davis

Commits

  1. Remove provider field from pg_locale_t.

  2. Control ctype behavior internally with a method table.

  3. Control collation behavior with a method table.

  4. Move code for collation version into provider-specific files.

  5. Refactor string case conversion into provider-specific files.

  6. Move check for ucol_strcollUTF8 to pg_locale_icu.c

  7. Perform provider-specific initialization in new functions.

  8. Refactor the code to create a pg_locale_t into new function.