Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
>
> I've posted a proposed patch to fix this. The patch requires an initdb
> (to add new sequence functions), so if we do that we may as well also
> fix the 32/64bit risk mentioned here:
> http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php
>
> Also, the floor seems open to discuss whether or not to revert the file
> access functions to their pre-beta2 APIs. I've got mixed feelings about
> that myself, but you can certainly make a case that the current
> definitions are not enough cleaner than what was there before to justify
> changing. This seems particularly true for pg_cancel_backend(), which
> already was in the core in 8.0.
I am thinking we should keep things as they are now.
I remember two changes of significance. First, pg_cancel_backend()'s
return value was change to boolean. I think the compelling argument
here is that we are adding other functions that _should_ return boolean,
and to keep pg_cancel_backend() as 1/0 was kind of strange. Also, I
assume pg_cancel_backend() is not a general use function and therefore
is more of an admin function that we can adjust as needed to improve the
API. We have always allowed rare/admin functions to be improved without
as much concern for backward compatibility as a more mainstream feature.
The other change was the rename of pg_complete_relation_size() to
pg_total_relation_size(). While there was a huge (exhausting)
discussion that finalized on pg_complete_relation_size(), a number of
people felt pg_total_relation_size() was better.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073