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
|
Список | 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 по дате отправления: