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

Reply via email to