Re: DEALLOCATE ALL
От | Heikki Linnakangas |
---|---|
Тема | Re: DEALLOCATE ALL |
Дата | |
Msg-id | 460FEDF3.8040204@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: DEALLOCATE ALL (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-patches |
Alvaro Herrera wrote: > Marko Kreen escribió: >> On 3/30/07, Alvaro Herrera <alvherre@commandprompt.com> wrote: > >>> In any case it's not likely that there are going to be thousands of >>> prepared statements, so is this really an issue? >> I think the issue is here that its very common thing to do, >> so open-coding it everywhere is waste, there should be some >> utility function for that. >> >> void hash_foreach(HTAB, void (*cb_func)(void *)); > > Extra points if you can implement a map() function for hashes ;-) (I > think it's called "mutator" in our sources for other kind of stuff) > > I think it would be > void *hash_map(HTAB, void *(*map_func) (void *)) > > Not sure what the return value would be though :-( (Maybe this is > extra complication enough that it's not worth the hassle) hash_map and hash_foreach seem like overkill to me, looping with hash_seq_search and doing stuff is simple enough that it doesn't really require any additional shorthands. Besides, to use them you'd always have to have a separate function and often a struct to pass down to the function, so it's not really any shorter or simpler. What would be useful is a hash_seq_remove-function that removes the previous item returned by hash_seq_search without the overhead of recalculating the hash value. While reviewing ITAGAKI's dead space map patch I noticed that he also added a hash_truncate function that removes all entries in the hash table, but unlike hash_destroy leaves the hash table intact. His implementation also calls hash_search(REMOVE) in a loop, which isn't the most efficient way to do it, but clearly there's need for more ways to empty a hash table. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: