Re: 答复: GiST API Adancement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Yuan Dong <Doffery(at)hotmail(dot)com>
Cc: "amborodin(at)acm(dot)org" <amborodin(at)acm(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 答复: GiST API Adancement
Date: 2017-06-16 14:06:16
Message-ID: 26271.1497621976@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Yuan Dong <Doffery(at)hotmail(dot)com> writes:
> ·¢¼þÈË: Andrew Borodin <borodin(at)octonica(dot)com>
>> I think there is one more aspect of development: backward
>> compatibility: it's impossible to update all existing extensions. This
>> is not that major feature to ignore them.

> I should still maintain original API of GiST after modification.

To put a little context on that: we have always felt that it's okay
to require extension authors to make small adjustments when going to
a new major release. For instance, adding a new parameter to a
globally visible function is fine, especially if callers can just
pass NULL or some such to get the old behavior. So in the context
here, you shouldn't feel compelled to come up with a bizarre API
design just to preserve exact compatibility of old code. You should
indeed think about reducing the amount of work that extension
authors have to do to update, but that doesn't have to mean "zero".
Also, it's wise to make sure that any places where code changes
have to be made will result in compile errors if the change isn't
made.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-06-16 14:10:41 Re: Getting server crash on Windows when using ICU collation
Previous Message Peter Eisentraut 2017-06-16 14:03:56 Re: Restrictions of logical replication