Re: NAMEDATALEN Changes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: NAMEDATALEN Changes
Дата
Msg-id 8565.1013698670@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: NAMEDATALEN Changes  (Greg Copeland <greg@CopelandConsulting.Net>)
Список pgsql-hackers
Greg Copeland <greg@CopelandConsulting.Net> writes:
> if we have a key with only 8-bytes of data and we iterrate over 128-bytes, 
> wouldn't the resulting hash be arbitrary and invalid as it would be hashing 
> memory which is not reflective of the key being hashed?

As long as we do it *consistently*, we can do it either way.  Using the
trailing nulls in the hash does alter the computed hash value --- but
we're only ever gonna compare the hash value against other hash values
computed on other NAMEs by this same routine.

This all assumes that the inputs are valid NAMEs, viz strlen <
NAMEDATALEN and no funny business beyond the first \0.  In practice,
however, if a bogus NAME were handed to us we would just as soon ignore
any characters beyond the first \0, because the ordering comparison
operators for NAME all do so (they're all based on strncmp), as do the
I/O routines etc.  So this change actually makes the system more
self-consistent not less so.
        regards, tom lane


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

Предыдущее
От: Greg Copeland
Дата:
Сообщение: Re: NAMEDATALEN Changes
Следующее
От: Chris Field
Дата:
Сообщение: Upgrading to 7.2