Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length

Alexander Korotkov <aekorotkov(at)gmail(dot)com> 于2024年11月8日周五 10:22写道：

> On Fri, Nov 8, 2024 at 4:05 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> > > On Thu, Nov 7, 2024 at 8:47 AM Tender Wang <tndrwang(at)gmail(dot)com> wrote:
> > >> Based on Tom's analysis, I provide a POC patch. I'm not sure if it
> is right
> > >> to use DEFAULT_COLLATION_OID in the patch.
> >
> > > Thank you. But I'm not sure about DEFAULT_COLLATION_OID.
> >
> > I don't quite trust that either. But since we only care about
> > equality, wouldn't it be OK to use C_COLLATION_OID?
> >
> > > Therefore, we can compare two text[] just with datumIsEqual().
> > > Attached patch implements this.
> >
> > I think this is nonsense. What about toasted datums, or even
> > just short-header ones? The one coming from an on-disk tuple
> > is pretty likely to be short-header for plausible sizes of
> > the options, but the one we just constructed in memory will
> > not be.
>
> You are correct. I quickly skim trough the sources and didn't find a
> function which compares detoasted contents of Datums excluding
> headers. So, yes, comparison using C-collation seems the most
> reasonable option.
>

No objection from me.

--
Thanks,
Tender Wang