Re: [PATCHES] updated hash functions for postgresql v1

On Wed, 2009-10-28 at 12:51 -0700, Jeff Davis wrote:
> On Wed, 2009-10-28 at 21:09 +0200, Hannu Krosing wrote:
> > Is at least the fact that they "are undocumented, have changed in the
> > past, and are likely to change again in the future" documented ?
>
> That's a little confusing to me: how do we document that something is
> undocumented? And where do we stop?

My previous e-mail message documents that the undocumentedness is
undocumented, so no need to go any further here ;)

Though undocumented, the hash functions are easily discoverable by doing

\df *hash*

in psql

> > Hashing is a quite fundamental thing in computing, so I was quite
> > surprised to find out it had silently changed.
>
> There are many reasons to use a hash, and we don't want people to use
> these functions for the wrong purpose.

I don't think that not documenting a hash function helps here at all.

> I have seen people use a
> performance hash for security purposes before, and I had to demonstrate
> some hash collisions to show why that was a bad idea.

I've seen people use CRC32 as hash and then hit a collisions in 15 tries
with quite large keys.

> So, if we do provide documented functions, it should be done carefully.

Any user-visible behavior change should be done carefully, even if the
original behavior is not documented.

Careful upgrade of hasxxx functions would have kept the old functions,
and introduced the new ones with _v2 suffix, and then used these in
appropriate places. then kept the old ones for a few versions, with
maybe a deprecation warning and then moved them to contrib for a few
more versions.

Doing it this way could leave them "undocumented" and still not break
peoples applications in mysterious ways.

> Trying to develop and document a set of standardized, stable hash
> functions covering a wide range of possible use cases sounds like it may
> be better served by an extension.

I guess there are enough security/crypt/strong hashes in pgcrypto
package so that should not be a problem.

--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training