On Thu, Apr 23, 2015 at 12:53 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
