Noah Misch writes:
> On Mon, Dec 14, 2020 at 01:59:03PM -0500, Tom Lane wrote:
>> Here's a rolled-up patch that does some further documentation work
>> and gets rid of the unnecessary memset's as well.
> +1 on removing the memset() calls. That said, it's not a big deal if more
> creep in over ti
On Mon, Dec 14, 2020 at 01:59:03PM -0500, Tom Lane wrote:
> * Should we just have a blanket insistence that all callers supply
> HASH_ELEM? The default sizes that dynahash.c uses without that are
> undocumented and basically useless.
+1
> we should just rip out all those memsets as pointless, si
Here's a rolled-up patch that does some further documentation work
and gets rid of the unnecessary memset's as well.
regards, tom lane
diff --git a/contrib/dblink/dblink.c b/contrib/dblink/dblink.c
index 2dc9e44ae6..651227f510 100644
--- a/contrib/dblink/dblink.c
+++ b/con
I wrote:
> There are a couple of other API oddities that maybe we should think
> about while we're here:
> * Should we just have a blanket insistence that all callers supply
> HASH_ELEM? The default sizes that dynahash.c uses without that are
> undocumented and basically useless. We're already a
Noah Misch writes:
> On Sun, Dec 13, 2020 at 11:49:31AM -0500, Tom Lane wrote:
>> A quick count of grep hits suggest that the large majority of
>> existing hash_create() calls use HASH_BLOBS, and there might be
>> only order-of-ten calls that would need to be touched if we
>> required an explicit
On Mon, Dec 14, 2020 at 1:36 AM Noah Misch wrote:
>
> On Sun, Dec 13, 2020 at 11:49:31AM -0500, Tom Lane wrote:
> > But what jumps out at me here is that this sort of error seems way
> > too easy to make, and evidently way too hard to detect. What can we
> > do to make it more obvious if one has
On 2020-12-13 17:49, Tom Lane wrote:
2. Don't allow a default: invent a new HASH_STRING flag, and
require that hash_create() calls specify exactly one of HASH_BLOBS,
HASH_STRING, or HASH_FUNCTION. This doesn't completely fix the
hazard of mindless-copy-and-paste, but I think it might make it
a l
On Sun, Dec 13, 2020 at 11:49:31AM -0500, Tom Lane wrote:
> But what jumps out at me here is that this sort of error seems way
> too easy to make, and evidently way too hard to detect. What can we
> do to make it more obvious if one has incorrectly used or omitted
> HASH_BLOBS? Both directions of
Amit Kapila writes:
> On Wed, Dec 9, 2020 at 2:56 PM Noah Misch wrote:
>> The problem is xidhash using strcmp() to compare keys; it needs memcmp().
> Your analysis is correct.
Sorry for not having noticed this thread before. Noah's fix is
clearly correct, and I have no objection to the added t
