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
