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, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
