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. We encountered, not long ago, a case where someone couldn't pg_upgrade from 9.0 to 9.2. The reason is that they had defined a view which happened to reference pg_stat_activity.procpid, which we renamed. Oops. Granted, few users do that, and granted, we can't always refrain from changing system catalog structure. But it seems to me that it's good to avoid the pain where we can. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
