Re: Rework manipulation and structure of attribute mappings
От | Amit Langote |
---|---|
Тема | Re: Rework manipulation and structure of attribute mappings |
Дата | |
Msg-id | CA+HiwqGFHa976Lfs_D4xSEddvtiZU0NrWktydehVeQhpRy7cmw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rework manipulation and structure of attribute mappings (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Rework manipulation and structure of attribute mappings
|
Список | 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
В списке pgsql-hackers по дате отправления: