Re: Collation versioning

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Collation versioning
Дата
Msg-id CAOBaU_Z1GgiiK__F2DbBzDM+xBb9Nxbe=4zszoOihRaZLyjNtA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Collation versioning  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: Collation versioning  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
On Thu, Jul 9, 2020 at 10:00 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2020-07-08 08:26, Michael Paquier wrote:
> > On Wed, Jul 08, 2020 at 06:12:51PM +1200, Thomas Munro wrote:
> >> I still wish I had a better idea than this:
> >>
> >> +/*
> >> + * Returns whether the given index access method depend on a stable collation
> >> + * order.
> >> + */
> >> +static bool
> >> +index_depends_stable_coll_order(Oid amoid)
> >> +{
> >> +       return (amoid != HASH_AM_OID &&
> >> +                       strcmp(get_am_name(amoid), "bloom") != 0);
> >> +}
> >>
> >> I'm doing some more testing and looking for weird cases...  More soon.
> >
> > Wouldn't the normal way to track that a new field in IndexAmRoutine?
> > What you have here is not extensible.
>
> Yeah, this should be decided and communicated by the index AM somehow.
>
> Perhaps it would also make sense to let the index AM handle the
> differences between deterministic and nondeterministic collations.  I
> don't know how the bloom AM works, though, to determine whether that
> makes sense.
>
> In order not to derail this patch set I think it would be okay for now
> to just include all index AMs in dependency tracking and invent a
> mechanism later that excludes hash and bloom in an extensible manner.

FTR I'll be happy to take care of that.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: replication_origin and replication_origin_lsn usage on subscriber
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions