Re: Declarative partitioning - another take
От | Amit Kapila |
---|---|
Тема | Re: Declarative partitioning - another take |
Дата | |
Msg-id | CAA4eK1LqTqZkPSoonF5_cOz94OUZG9j0PNfLdhi_nPtW82fFVA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Declarative partitioning - another take (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: Declarative partitioning - another take
|
Список | pgsql-hackers |
On Wed, Oct 26, 2016 at 8:27 AM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > On 2016/10/26 11:41, Amit Kapila wrote: >> On Wed, Oct 26, 2016 at 6:36 AM, Amit Langote >> <Langote_Amit_f8@lab.ntt.co.jp> wrote: >>>> 1. >>>> @@ -1775,6 +1775,12 @@ BeginCopyTo(ParseState *pstate, >>>> { >>>> .. >>>> + else if (rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE) >>>> + ereport(ERROR, >>>> + (errcode(ERRCODE_WRONG_OBJECT_TYPE), >>>> + errmsg("cannot copy from partitioned table \"%s\"", >>>> + RelationGetRelationName(rel)), >>>> + errhint("Try the COPY (SELECT ...) TO variant."))); >>>> .. >>>> } >>>> >>>> Why is this restriction? Won't it be useful to allow it for the cases >>>> when user wants to copy the data of all the partitions? >>> >>> Sure, CopyTo() can be be taught to scan leaf partitions when a partitioned >>> table is specified, but I thought this may be fine initially. >>> >> >> Okay, I don't want to add anything to your existing work unless it is >> important. However, I think there should be some agreement on which >> of the restrictions are okay for first version of patch. This can >> avoid such questions in future from other reviewers. > > OK, so I assume you don't find this particular restriction problematic in > long term. > I think you can keep it as you have in patch. After posting your updated patches, please do send a list of restrictions which this patch is imposing based on the argument that for first version they are not essential. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: