clarify equalTupleDescs()

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: clarify equalTupleDescs()
Date: 2024-02-06 12:59:18
Message-ID: f656d6d9-6660-4518-a006-2f65cafbebd1@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

In a recent patch thread it was discussed[0] which fields should be
compared by equalTupleDescs() and whether it is ok to remove a field
from tuple descriptors and how that should affect their equality
(attstattarget in that case).

After analyzing all the callers, I have noticed that there are two
classes of callers of equalTupleDescs():

The first want to compare what I call row-type equality, which means
they want to check specifically for equal number of attributes, and the
same attribute names, types, and typmods for each attribute. Most
callers actually want that behavior. The remaining callers just want to
compare the tuple descriptors as they are, they don't care why the
fields are in there, they just want to compare all of them.

In the attached patch, I add a new function equalRowTypes() that is
effectively a subset of equalTupleDescs() and switch most callers to that.

The purpose of this patch is to make the semantics less uncertain.
Questions like the one in [0] about attstattarget now have a clear
answer for both functions. I think this would be useful to have, as we
are thinking about more changes in pg_attribute and tuple descriptors.

[0]:
https://www.postgresql.org/message-id/202401101316.k4s3fomwjx52@alvherre.pgsql

Attachment Content-Type Size
v0-0001-Separate-equalRowTypes-from-equalTupleDescs.patch text/plain 10.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2024-02-06 13:00:00 Re: Race condition in FetchTableStates() breaks synchronization of subscription tables
Previous Message Ashutosh Bapat 2024-02-06 12:51:38 Re: Memory consumed by paths during partitionwise join planning