Have collation versioning to ignore hash and similar AM

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Have collation versioning to ignore hash and similar AM
Date: 2020-11-26 07:09:27
Message-ID: 20201126070927.GA59491@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

Collation versioning has been committed, but there are still at least 2 cases
that aren't perfectly handled:

- AMs which don't rely on stable collation ordering (hash, bloom...)
- expressions which don't rely on a stable collation ordering (e.g. md5())

Handling expressions will probably require a lot of work, so I'd like to start
with AM handling.

My initial idea was to add a new field in IndexAmRoutine for that (see patch
[1] that was present in v30 [2], and the rest of the patches that used it).
Does anyone have any suggestion on a better way to handle that?

Note also that in the patch I named the field "amnostablecollorder", which is a
bit weird but required so that a custom access method won't be assumed to not
rely on a stable collation ordering if for some reason the author forgot to
correctly set it up. If we end up with a new field in IndexAmRoutine, maybe we
could also add an API version field that could be bumped in case of changes so
that authors get an immediate error? This way we wouldn't have to be worried
of a default value anymore.

[1] https://www.postgresql.org/message-id/attachment/114354/v30-0001-Add-a-new-amnostablecollorder-flag-in-IndexAmRou.patch
[2] https://www.postgresql.org/message-id/20200924094854.abjmpfqixq6xd4o5%40nol

Browse pgsql-hackers by date

  From Date Subject
Next Message Luc Vlaming 2020-11-26 07:11:22 Re: Parallel plans and "union all" subquery
Previous Message Masahiro Ikeda 2020-11-26 07:07:37 Re: Add statistics to pg_stat_wal view for wal related parameter tuning