Re: Open items list for 8.1

Jim C. Nasby wrote:
> 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.

We don't have the ability to have to functions that take the same
parameters and return different results because there is no facility to
decide which function to call based on what return value is expected,
because a simple query doesn't have a return value restriction:

SELECT pg_cancel_backend();

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073