Re: Collation & ctype method table, and extension hooks

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>, pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: Collation & ctype method table, and extension hooks
Date: 2025-02-07 19:19:21
Message-ID: cb580fec46ea4ca96dd4bbde9d2769360e097d01.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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

Attachment Content-Type Size
v15-0001-Control-ctype-behavior-internally-with-a-method-.patch text/x-patch 43.0 KB
v15-0002-Remove-provider-field-from-pg_locale_t.patch text/x-patch 4.8 KB
v15-0003-Make-provider-data-in-pg_locale_t-an-opaque-poin.patch text/x-patch 25.6 KB
v15-0004-Don-t-include-ICU-headers-in-pg_locale.h.patch text/x-patch 2.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2025-02-07 19:21:07 Re: Trigger more frequent autovacuums of heavy insert tables
Previous Message James Hunter 2025-02-07 19:11:24 Re: should we have a fast-path planning for OLTP starjoins?