On Thu, Apr 23, 2015 at 12:53 PM, Andres Freund <andres@anarazel.de> wrote:
> Unconvinced. Not breaking an API has its worth.
Yeah, and I acknowledge that - but it's not something that it's
appropriate to encapsulate IMV.
Let's just leave it to Heikki...I'd say he has the deciding vote,
especially as the reviewer that is more in charge of the executor
stuff than anything else.
>> The second most significant open item is rebasing on top of the recent
>> RLS changes, IMV.
>
> Not sure I agree. That part seems pretty mechanical to me.
Hopefully so.
> * The docs aren't suitable for endusers. I think this will take a fair
> amount of work.
It's hard to explain why something like the collation field in the
inference specification matters to users...because it's only supported
at all due to forwards compatibility concerns. It's hard to document
certain things like that in an accessible way. In general, much of the
effort of the last year was making the feature play nice, and
considering a bunch of usability edge cases that are unlikely to come
up, but still must be documented.
> * We're not yet sure about the syntax yet. In addition to the keyword
> issue I'm unconvinced about having two WHERE clauses in the same
> statement. I think that'll end up confusing users a fair bit. Might
> still be the best way forward.
My previous approach to allowing an index predicate did at least
clearly show that the predicate belonged to the inference
specification, since it appeared between parenthesis. Maybe we should
do that after all? I don't think it much matters if the inference
specification is not identical to CREATE INDEX. I don't want to give
up inference of partial indexes, and I don't want to give up allowing
the UPDATE to have a limited WHERE clause, and we can't just spell
those differently here. So what alternative does that leave?
Anyone else have an opinion?
> * The executor integration still isn't pretty, although Heikki is making
> strides there
That's just clean-up, though. I'm not worried about the risk of Heikki
not succeeding at that.
> * I don't think anybody seriously has looked at the planner side yet.
Good point. That certainly needs to be looked at (and I include the
rewriter parts in that). It's really not that much code, but (ideally)
a subject matter expert should look into the whole ExcludedExpr dance
in particular.
--
Peter Geoghegan