forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit4d969b2
committed
MergeAttributes: convert pg_attribute back to ColumnDef before comparing
MergeAttributes() has a loop to merge multiple inheritance parentsinto a column column definition. The merged-so-far definition isstored in a ColumnDef node. If we have to merge columns from multipleinheritance parents (if the name matches), then we have to checkwhether various column properties (type, collation, etc.) match. Thecurrent code extracts the pg_attribute value of thecurrently-considered inheritance parent and compares it against themerged-so-far ColumnDef value. If the currently considered columndoesn't match any previously inherited column, we make a new ColumnDefnode from the pg_attribute information and add it to the column list.This patch rearranges this so that we create the ColumnDef node firstin either case. Then the code that checks the column properties forcompatibility compares ColumnDef against ColumnDef (instead ofColumnDef against pg_attribute). This makes the code more symmetricand easier to follow. Also, later in MergeAttributes(), there is asimilar but separate loop that merges the new local column definitionwith the combination of the inheritance parents established in thefirst loop. That comparison is already ColumnDef-vs-ColumnDef. Withthis change, both of these can use similar-looking logic. (A futureproject might be to extract these two sets of code into a commonroutine that encodes all the knowledge of whether two columndefinitions are compatible. But this isn't currently straightforwardbecause we want to give different error messages in the two cases.)Furthermore, by avoiding the use of Form_pg_attribute here, we make iteasier to make changes in the pg_attribute layout without having toworry about the local needs of tablecmds.c.Because MergeAttributes() is hugely long, it's sometimes hard to knowwhere in the function you are currently looking. To help with that, Ialso renamed some variables to make it clearer where you are currentlylooking. The first look is "prev" vs. "new", the second loop is "inh"vs. "new".Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>Discussion:https://www.postgresql.org/message-id/flat/52a125e4-ff9a-95f5-9f61-b87cf447e4da@eisentraut.org1 parent4677818 commit4d969b2
1 file changed
+102
-96
lines changed0 commit comments
Comments
(0)