Re: NAMEDATALEN Changes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: NAMEDATALEN Changes
Date
Msg-id 8565.1013698670@sss.pgh.pa.us
Whole thread Raw
In response to Re: NAMEDATALEN Changes  (Greg Copeland <greg@CopelandConsulting.Net>)
List 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 by date:

Previous
From: Greg Copeland
Date:
Subject: Re: NAMEDATALEN Changes
Next
From: Chris Field
Date:
Subject: Upgrading to 7.2