Re: Indexes on partitioned tables and foreign partitions
От | Michael Paquier |
---|---|
Тема | Re: Indexes on partitioned tables and foreign partitions |
Дата | |
Msg-id | 20180510010203.GC26879@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Indexes on partitioned tables and foreign partitions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Indexes on partitioned tables and foreign partitions
|
Список | pgsql-hackers |
On Wed, May 09, 2018 at 11:10:43AM -0400, Tom Lane wrote: > Agreed about unique indexes. I suggest that we throw an error for both > cases, because (1) having unique and non-unique indexes behave differently > for this purpose seems pretty weird; (2) throwing an error now preserves > our options to do something different later. Given where we are in the > release cycle, we should be taking the most conservative path we can. Heartfully agreed to throw an error for all cases for now. Something that I find confusing on HEAD though is that DefineIndex calls itself around line 1006 and cascades through each children but there is no context about the error. For example if I have this partition layer: CREATE TABLE measurement ( logdate date not null, peaktemp int, unitsales int ) PARTITION BY RANGE (logdate); CREATE FOREIGN TABLE measurement_y2016m07 PARTITION OF measurement FOR VALUES FROM ('2016-07-01') TO ('2016-08-01') SERVER postgres_server; Then by creating an index on the parent I get that: =# create index measurement_idx on measurement (peaktemp); ERROR: 42809: cannot create index on foreign table "measurement_y2016m07" LOCATION: DefineIndex, indexcmds.c:442 This may be confusing for the user as the DDL does not complain directly about the relation worked on. Perhaps we could add an error context? We surely don't want multiple contexts either when working on long chains, but we could build a chained list of relation names in the error message. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: