Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, May 9, 2018 at 9:08 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Shouldn't the fix be to allow creation of indexes on foreign tables?
>> (Maybe they would be virtual or foreign indexes??)
> It might be useful to invent the concept of a foreign index, but not
> for v11 a month after feature freeze.
Yeah. That's a can of worms we can *not* open at this stage.
> For right now, I think the options are (1) throw an ERROR if we
> encounter a foreign table or (2) silently skip the foreign table. I
> think (2) is defensible for non-UNIQUE indexes, because the index is
> just a performance optimization. However, for UNIQUE indexes, at
> least, it seems like we'd better do (1), because a major point of such
> an index is to enforce a constraint; we can't allege that we have such
> a constraint if foreign tables are just silently skipped.
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.
regards, tom lane
