Re: Collation & ctype method table, and extension hooks - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Collation & ctype method table, and extension hooks
Date
Msg-id 442af5a9-4f6e-4bc8-ad8e-e22d557ab2b9@eisentraut.org
Whole thread Raw
In response to Re: Collation & ctype method table, and extension hooks  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
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.




pgsql-hackers by date:

Previous
From: Ian Lawrence Barwick
Date:
Subject: Re: regdatabase
Next
From: Peter Eisentraut
Date:
Subject: Re: Adding support for SSLKEYLOGFILE in the frontend