Re: Open items list for 8.1

On Wed, Sep 28, 2005 at 06:07:02PM -0400, Neil Conway wrote:
> On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote:
> > The problem isn't whether or not they should be changed, the problem is
> > that they were changed *during* beta AND *against* the direction that
> > discussion on these changes went
>
> I'm not sure what you mean: what is "the direction that discusson on
> these changes went"? (If you're referring to "complete" vs. "total",
> that hardly constitutes a change in direction.)
>
> > ... pre-beta would have been more acceptable, but pre-feature freeze
> > would have been much preferred
>
> I think there is an argument to be made for reverting pg_cancel_backend,
> since that function was released with 8.0. Personally I'm sceptical that
> there are very many people using that function in scripts (particularly
> using it in such a way that their scripts will break if the return type
> is changed). Since we've already made the change, I don't really see the
> point in reverting it, but I don't mind if someone wants to do it.

I think it's just as important to work towards keeping interfaces clean
as it is not to break old code.

What's wrong with adding pg_cancel_backend(...) RETURNS int as an alias
for the one that returns boolean, and document that it's deprecated and
will be removed in the future.

The same goes for Tom's timeofday() RETURNS text example.

> As for the other changes, I think there is absolutely no reason to
> revert them. Since when is making changes to the signatures of new
> functions forbidden during the beta period? AFAIK we don't make
> guarantees of backward compatibility during the beta period, nor would
> it be sensible to do so. We had the opportunity to fix some poor API
> choices, and since an initdb was already required I think making these
> changes for beta2 was quite reasonable.

Agreed. Not making API changes now means we get to live with them for
years and years.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461