> -----Original Message-----
> From: Michael Paquier [mailto:michael.paquier@gmail.com]
> Sent: Wednesday, July 15, 2015 3:29 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Tom Lane; Robert Haas; Alvaro Herrera; hlinnaka; Jim Nasby; Kohei KaiGai;
> PgHacker; Simon Riggs
> Subject: Re: ctidscan as an example of custom-scan (Re: [HACKERS] [v9.5] Custom
> Plan API)
>
> On Wed, Jul 15, 2015 at 10:12 AM, Kouhei Kaigai <kaigai@ak.jp.nec.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.
>
Yep, I also don't want to break the interface compatibility without
something reasonable, and also think following-up new core features
is a good reason to enhance the interface in the future version.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>