Re: NAMEDATALEN Changes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Copeland <greg(at)CopelandConsulting(dot)Net>
Cc: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: NAMEDATALEN Changes
Date: 2002-02-14 14:57:50
Message-ID: 8565.1013698670@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Copeland <greg(at)CopelandConsulting(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Field 2002-02-14 16:25:00 Upgrading to 7.2
Previous Message Greg Copeland 2002-02-14 14:00:58 Re: NAMEDATALEN Changes