Re: Declarative partitioning - another take
От | Amit Langote |
---|---|
Тема | Re: Declarative partitioning - another take |
Дата | |
Msg-id | df25acb0-beb6-4373-31f3-d440b25c3e91@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Declarative partitioning - another take (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On 2016/11/02 16:41, Amit Langote wrote: > Having said all that, I am open to switching to the catalogued partition > constraints if the arguments I make above in favor of this patch are not > all that sound. One problem I didn't immediately see a solution for if we go with the catalogued partition constraints is how do we retrieve a relation's partition constraint? There are a couple of cases where that becomes necessary. Consider that we are adding a partition to a partitioned table that is itself partition. In this case, the new partition's constraint consists of whatever we generate from its FOR VALUES specification *ANDed* with the parent's constraint. We must somehow get hold of the latter. Which of the parent's named check constraints in the pg_constraint catalog is supposed to be the partition constraint? With the uncatalogued partition constraints approach, we simply generate it from the parent's pg_class.relpartbound (or we might get the relcache copy of the same stored in rd_partcheck). Hmm. Thanks, Amit
В списке pgsql-hackers по дате отправления: