Re: [HACKERS] expanding inheritance in partition bound order
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] expanding inheritance in partition bound order |
Дата | |
Msg-id | CA+Tgmoafr=hUrM=cbx-k=BDHOF2OfXaw95HQSNAK4mHBwmSjtw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] expanding inheritance in partition bound order (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] expanding inheritance in partition bound order
Re: [HACKERS] expanding inheritance in partition bound order |
Список | pgsql-hackers |
On Tue, Aug 29, 2017 at 10:36 PM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: >> I keep having the feeling that this is a big patch with a small patch >> struggling to get out. Is it really necessary to change >> RelationGetPartitionDispatchInfo so much or could you just do a really >> minimal surgery to remove the code that sets the stuff we don't need? >> Like this: > > Sure, done in the attached updated patch. On first glance, that looks pretty good. I'll have a deeper look tomorrow. It strikes me that if PartitionTupleRoutingInfo is an executor structure, we should probably (as a separate patch) relocate FormPartitionKeyDatum and get_partition_for_tuple to someplace in src/backend/executor and rename the accordingly; maybe it's time for an execPartition.c? catalog/partition.c is getting really bug, so it's not a bad thing if some of that stuff gets moved elsewhere. A lingering question in my mind, though, is whether it's really correct to think of PartitionTupleRoutingInfo as executor-specific. Maybe we're going to need that for other things too? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: