On Wed, Mar 22, 2023 at 9:01 PM David Rowley <dgrowleyml@gmail.com> wrote:
> On Thu, 23 Mar 2023 at 16:25, Peter Geoghegan <pg@bowt.ie> wrote:
> > Have you seen the comments about the cstring/name_ops hack mentioning
> > a SIGSEGV in btrescan()? Those were added around the time index-only
> > scans first went in.
>
> I'd not seen it. That's a bit disappointing. Is all this just to work
> around not having to store the full 64 bytes for a name in indexes?
Yes, that's the whole point of the hack.
> Seems it there are a few hacks that try to make this work. I wonder
> if we should just invent new hacks in the form of a new version of
> datum_image_eq that accepts a pointer to a FormData_pg_attribute
> instead of typByVal and typLen then just special case NAMEOID types to
> always compare as cstrings. Same for datum_image_hash().
The only reason why datum_image_eq() has support for cstring is B-Tree
deduplication; cstring support was added to allow nbtdedup.c to deal
with name/cstring indexes sensibly. So the fact that datum_image_eq()
can compare cstrings in the first place is in fact related to the same
general issue with name_ops.
--
Peter Geoghegan