Re: partition tree inspection functions
От | Michael Paquier |
---|---|
Тема | Re: partition tree inspection functions |
Дата | |
Msg-id | 20181003033718.GD2609@paquier.xyz обсуждение исходный текст |
Ответ на | Re: partition tree inspection functions (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: partition tree inspection functions
Re: partition tree inspection functions Re: partition tree inspection functions |
Список | pgsql-hackers |
On Mon, Oct 01, 2018 at 04:27:57PM +0900, Amit Langote wrote: > Yeah, maybe there is no reason to delay proceeding with > pg_partition_children which provides a useful functionality. So, I have been looking at your patch, and there are a couple of things which could be improved. Putting the new function pg_partition_children() in partition.c is a bad idea I think. So instead I think that we should put that in a different location, say utils/adt/partitionfuncs.c. + TupleDescInitEntry(tupdesc, (AttrNumber) 1, "relid", + REGCLASSOID, -1, 0); + TupleDescInitEntry(tupdesc, (AttrNumber) 2, "parentid", + REGCLASSOID, -1, 0); REGCLASSOID is used mainly for casting, so instead let's use OIDOID like any other system function. + values[2] = psprintf("%d", level); + values[3] = psprintf("%c", relkind == RELKIND_PARTITIONED_TABLE ? + 'f' : + 't'); Using Datum objects is more elegant in this context. isleaf is not particularly useful as it can just be fetched with a join on pg_class/relkind. So I think that we had better remove it. I have cleaned up a bit tests, removing duplicates and most of the things which touched the size of relations to have something more portable. We could have a flavor using a relation name in input with qualified names handled properly (see pg_get_viewdef_name for example), not sure if that's really mandatory so I left that out. I have also added some comments here and there. The docs could be worded a bit better still. My result is the patch attached. What do you think? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: