Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)
От | Zdenek Kotala |
---|---|
Тема | Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4) |
Дата | |
Msg-id | 1243345474.1296.52.camel@localhost обсуждение исходный текст |
Ответ на | Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane píše v po 25. 05. 2009 v 13:07 -0400: > Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes: > > Tom Lane píše v ne 24. 05. 2009 v 18:46 -0400: > >> In any case, the barriers to implementing 8.3-style hash indexes in 8.4 > >> are pretty huge: you'd need to duplicate not only the hash AM code, but > >> also all the hash functions, and therefore all of the hash pg_amop and > >> pg_amproc entries. > > > I'm not sure if I need duplicate functions. Generally yes but It seems > > to me that hash index does not changed functions behavior and they could > > be shared at this moment. > > No, the behavior of the hash functions themselves changed during 8.4. > Twice, even: hmm, I'm missed it. :( > So as far as I can see, you need completely separate copies of both > hash_any() and the SQL-level functions that call it. I'm not really > seeing that the proposed refactoring makes this any easier. You might > as well just copy-and-paste all that old code into a separate set of > files, and not worry about what is in access/hash.h. Yeah, in this case everything have to be duplicated which is not big deal in comparison to do same amount of work for GIN. Then I can start with GIN. The advantage of refactoring is then only nicer code. thanks Zdenek
В списке pgsql-hackers по дате отправления: