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 |
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 |