Re: Fix pgstattuple/pgstatindex to use regclass-type as the argument

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Satoshi Nagayasu <snaga(at)uptime(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fix pgstattuple/pgstatindex to use regclass-type as the argument
Date: 2013-03-05 13:46:15
Message-ID: CA+Tgmoaco-1OPb-eHMLkZy3Wo2rHF=nOgx5488Hjx10EswWJUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 3, 2013 at 5:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-03-05 13:46:37 Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Previous Message Michael Paquier 2013-03-05 13:35:16 Re: Support for REINDEX CONCURRENTLY