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