Andreas Karlsson <andr...@proxel.se> writes:
> On 1/19/22 09:30, Peter Eisentraut wrote:
>> I don't have a lot of experience with this module, so I don't know if
>> there are any lingering concerns about whether it is mature enough as a
>> built-in feature.
> While it I like the idea on a conceptual level I worry about the code
> quality of the module. I know that the btree/cidr code is pretty broken.
> But I am not sure if there are any issues with other data types.
Yeah :-(. We just fixed an issue with its char(n) support too
(54b1cb7eb), so I don't have a terribly warm feeling about the
quality of the lesser-used code paths. Still, maybe we could
do some code review/testing rather than a blind copy & paste.
I'd also opine that we don't have to preserve on-disk compatibility
while migrating into core, which'd help get out of the sticky problem
for inet/cidr. This'd require being able to run the contrib module
alongside the core version for awhile (to support existing indexes),
but I think we could manage that if we tried. IIRC we did something
similar when we migrated tsearch into core.
One thing I don't know anything about is how good are btree_gist
indexes performance-wise. Do they have problems that we'd really
need to fix to consider them core-quality?
regards, tom lane
