(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.
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?
Regards,
--
Satoshi Nagayasu <sn...@uptime.jp>
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
