Re: clarify equalTupleDescs()

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: clarify equalTupleDescs()
Дата
Msg-id 2b23d40b-27a3-4629-a331-32554587307c@eisentraut.org
обсуждение исходный текст
Ответ на Re: clarify equalTupleDescs()  (jian he <jian.universality@gmail.com>)
Ответы Re: clarify equalTupleDescs()  (jian he <jian.universality@gmail.com>)
Список 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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Add publisher and subscriber to glossary documentation.
Следующее
От: "Pavlo Golub"
Дата:
Сообщение: Re[2]: [PATCH] allow pg_current_logfile() execution under pg_monitor role