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

From: Satoshi Nagayasu <snaga(at)uptime(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fix pgstattuple/pgstatindex to use regclass-type as the argument
Date: 2013-03-09 06:23:01
Message-ID: 513AD545.8070307@uptime.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(2013/03/05 22:46), Robert Haas wrote:
> 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.

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 <snaga(at)uptime(dot)jp>
Uptime Technologies, LLC. http://www.uptime.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ian Pilcher 2013-03-09 08:52:43 Re: Trust intermediate CA for client certificates
Previous Message Michael Paquier 2013-03-09 04:35:28 Re: Request for vote to move forward with recovery.conf overhaul