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

From: Satoshi Nagayasu <snaga(at)uptime(dot)jp>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-06-20 02:43:43
Message-ID: 51C26C5F.8000306@uptime.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(2013/06/17 4:02), Fujii Masao wrote:
> On Sat, Mar 9, 2013 at 3:23 PM, Satoshi Nagayasu <snaga(at)uptime(dot)jp> wrote:
>> 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?

AFAIK, a regclass type argument would accept an OID value,
which means regclass type has upper-compatibility against
oid type.

So, even if the declaration is changed, compatibility could
be kept actually. This test case (in sql/pgstattuple.sql)
confirms that.

----------------------------------------------------------------
select * from pgstatindex('myschema.test_pkey'::regclass::oid);
version | tree_level | index_size | root_block_no | internal_pages |
leaf_pages | empty_pages | deleted_pages | avg_leaf_density |
leaf_fragmentation
---------+------------+------------+---------------+----------------+------------+-------------+---------------+------------------+--------------------
2 | 0 | 8192 | 1 | 0 |
1 | 0 | 0 | 0.79 |
0
(1 row)
----------------------------------------------------------------

>> 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'm still considering changing the function name as Tom pointed
out. How about "pgstatbtindex"?

In fact, pgstatindex does support only BTree index.
So, "pgstatbtindex" seems to be more appropriate for this function.

We can keep having both (old) pgstatindex and (new) pgstatbtindex
during next 2-3 major releases, and the old one will be deprecated
after that.

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 Satoshi Nagayasu 2013-06-20 03:26:20 Re: Add visibility map information to pg_freespace.
Previous Message Andrew Dunstan 2013-06-20 02:35:53 Re: slightly confusing JSON error context