Re: ctidscan as an example of custom-scan (Re: [v9.5] Custom Plan API)

On Wed, Jul 15, 2015 at 2:28 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Wed, Jul 15, 2015 at 10:12 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
>> We never guarantee the interface compatibility between major version up.
>> If we add/modify interface on v9.6, it is duty for developer of extensions
>> to follow the new version, even not specific to custom-scan provider.
>> If v9.6 adds support fine-grained function cost estimation, I also have
>> to follow the feature, but it is natural.
>
> Maintaining compatibility across major versions is a best-effort and
> even if we sometimes break things across major versions, and sometimes
> even silently (take the example of 9.3's background worker that do not
> start with 9.4 as long as bgw_notify_pid is not set to 0), the
> approach is usually taken to have APIs stable and convenient able to
> cover a maximum set of cases for a given set of plugins, and this
> serves well in the long term. Now it is true that we cannot assume
> either that the version of a plugin API will be perfect forever and
> will be able to cover all the imagined test cases at first shot, still
> I'd like to think that things are broken only when necessary and with
> good reasons. A set of APIs changed at each major release tends to be
> proof that research lacked in the first version, and would surely
> demotivate its adoption by extension developers.

Maybe. If those changes are demanded by extension developers who are
trying to do useful stuff with the APIs and finding problems, then
changing things will probably make those extension developers happy.
If the changes are necessitated by core improvements, then we might
get some complaints if those core improvements are perceived to have
small value compared to the API break. But I think complaints of that
kind are very rare. The only thing I can think of that falls into
approximately that category is a gripe about the replacement of
relistemp by relpersistence. But I think that was more motivated by
the way it broke SQL monitoring queries than by the way it broke C
code. There may be other more recent examples; but that's the only
one I can think of offhand. I just don't see it as a big issue.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company