On Fri, Oct 13, 2017 at 1:59 PM, Peter Geoghegan <pg@bowt.ie> wrote: >> Fully agreed. > > If we implement that interface, where does that leave EvalPlanQual()?
From the first glance, it seems that pluggable storage should override EvalPlanQualFetch(), rest of EvalPlanQual() looks quite generic.
> Do those semantics have to be preserved?
For a general-purpose heap storage format, I would say yes.
+1
I mean, we don't really have control over how people use the API. If somebody decides to implement a storage API that breaks EvalPlanQual semantics horribly, I can't stop them, and I don't want to stop them. Open source FTW.
Yeah. We don't have any kind of "safe extensions". Any extension can break things really horribly.
For me that means user should absolutely trust extension developer.
But I don't really want that code in our tree, either.
We keep things in our tree as correct as we can. And for sure, we should
follow this politics for pluggable storages too.
I think a storage engine is and should be about the format in which data gets stored on disk, and that it should only affect the performance of queries not the answers that they give.
Pretty same idea as index access methods. They also affects the
performance, but not query answers. When it's not true, this situation
is considered as bug, and it needs to be fixed.
I am sure there will be cases where, for reasons of implementation complexity, that turns out not to be true, but I think in general we should try to avoid it as much as we can.
I think in some cases we can tolerate missing features (and document it),
but don't tolerate wrong features. For instance, we may have some pluggable
storage which doesn't support transactions at all (and that should be
documented for sure), but we shouldn't have pluggable storage which