On Sat, Mar 9, 2013 at 3:23 PM, Satoshi Nagayasu <sn...@uptime.jp> wrote: > (2013/03/05 22:46), Robert Haas wrote: >> >> On Sun, Mar 3, 2013 at 5:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> >>> Maybe this is acceptable collateral damage. I don't know. But we >>> definitely stand a chance of breaking applications if we change >>> pgstatindex like this. It might be better to invent a differently-named >>> function to replace pgstatindex. >> >> >> If this were a built-in function, we might have to make a painful >> decision between breaking backward compatibility and leaving this >> broken forever, but as it isn't, we don't. I think your suggestion of >> adding a new function is exactly right. We can remove the old one in >> a future release, and support both in the meantime. It strikes me >> that if extension versioning is for anything, this is it. > > > It is obviously easy to keep two types of function interfaces, > one with regclass-type and another with text-type, in the next > release for backward-compatibility like below: > > pgstattuple(regclass) -- safer interface. > pgstattuple(text) -- will be depreciated in the future release.
So you're thinking to remove pgstattuple(oid) soon? > Having both interfaces for a while would allow users to have enough > time to rewrite their applications. > > Then, we will be able to obsolete (or just drop) old interfaces > in the future release, maybe 9.4 or 9.5. I think this approach > would minimize an impact of such interface change. > > So, I think we can clean up function arguments in the pgstattuple > module, and also we can have two interfaces, both regclass and text, > for the next release. > > Any comments? In the document, you should mark old functions as deprecated. I changed the status of this patch to "Waiting on Author". Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
