Re: Rework manipulation and structure of attribute mappings
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-12-17T04:54:27Z
Lists: pgsql-hackers
Hi Michael, On Mon, Dec 9, 2019 at 11:57 AM Michael Paquier <michael@paquier.xyz> wrote: > On Fri, Dec 06, 2019 at 06:03:12PM +0900, Amit Langote wrote: > > Sorry I don't understand this. Do you mean we should rename the > > routines left behind in tupconvert.c? For example, > > convert_tuples_by_name() doesn't really "convert" tuples, only builds > > a map needed to do so. Maybe build_tuple_conversion_map_by_name() > > would be a more suitable name. > > I had no plans to touch this area nor to rename this layer because > that was a bit out of the original scope of this patch which is to > remove the confusion and random bets with map lengths. I see your > point though and actually a name like what you are suggesting reflects > better what the routine does in reality. :p Maybe another day. :) > So, a couple of hours after looking at the code I am finishing with > the updated and indented version attached. What do you think? Thanks for the updated patch. I don't have any comments, except that the text I suggested couple of weeks ago no longer reads clear: + * by DDL operating on inheritance and partition trees to convert fully + * transformed expression trees from parent rowtype to child rowtype or + * vice-versa. Maybe: ...to adjust the Vars in fully transformed expression trees to bear output relation's attribute numbers. Thanks, Amit
Commits
-
Refactor attribute mappings used in logical tuple conversion
- e1551f96e643 13.0 landed