Re: ctidscan as an example of custom-scan (Re: [v9.5] Custom Plan API)
От | Kouhei Kaigai |
---|---|
Тема | Re: ctidscan as an example of custom-scan (Re: [v9.5] Custom Plan API) |
Дата | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F8011163FB@BPXM15GP.gisp.nec.co.jp обсуждение исходный текст |
Ответ на | Re: ctidscan as an example of custom-scan (Re: [v9.5] Custom Plan API) (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
> -----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>
В списке pgsql-hackers по дате отправления: