Re: clarify equalTupleDescs()

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: clarify equalTupleDescs()
Date: 2024-02-12 11:46:57
Message-ID: 2b23d40b-27a3-4629-a331-32554587307c@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07.02.24 04:06, jian he wrote:
> /*
> * hashRowType
> *
> * If two tuple descriptors would be considered equal by equalRowTypes()
> * then their hash value will be equal according to this function.
> */
> uint32
> hashRowType(TupleDesc desc)
> {
> uint32 s;
> int i;
>
> s = hash_combine(0, hash_uint32(desc->natts));
> s = hash_combine(s, hash_uint32(desc->tdtypeid));
> for (i = 0; i < desc->natts; ++i)
> s = hash_combine(s, hash_uint32(TupleDescAttr(desc, i)->atttypid));
>
> return s;
> }
>
> from the hashRowType comment, should we also hash attname and atttypmod?

In principle, hashRowType() could process all the fields that
equalRowTypes() does. But since it's only a hash function, it doesn't
have to be perfect. (This is also the case for the current
hashTupleDesc().) I'm not sure where the best tradeoff is.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavlo Golub 2024-02-12 12:27:54 Re[2]: [PATCH] allow pg_current_logfile() execution under pg_monitor role
Previous Message Alvaro Herrera 2024-02-12 11:26:40 Re: Add publisher and subscriber to glossary documentation.