On Tue, Jul 16, 2013 at 3:00 PM, Satoshi Nagayasu <sn...@uptime.jp> wrote:
> (2013/07/04 3:58), Fujii Masao wrote:
>> On Wed, Jun 26, 2013 at 12:39 AM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Thu, Jun 20, 2013 at 2:32 PM, Fujii Masao <masao.fu...@gmail.com> wrote:
>>>> Since pg_relpages(oid) doesn't exist, pg_relpages() is in the same
>>>> situation as pgstatindex(), i.e., we cannot just replace pg_relpages(text)
>>>> with pg_relpages(regclass) for the backward-compatibility. How do you
>>>> think we should solve the pg_relpages() problem? Rename? Just
>>>> add pg_relpages(regclass)?
>>>
>>> Adding a function with a new name seems likely to be smoother, since
>>> that way you don't have to worry about problems with function calls
>>> being thought ambiguous.
>>
>> Could you let me know the example that this problem happens?
>>
>> For the test, I just implemented the regclass-version of pg_relpages()
>> (patch attached) and tested some cases. But I could not get that problem.
>>
>> SELECT pg_relpages('hoge'); -- OK
>> SELECT pg_relpages(oid) FROM pg_class WHERE relname = 'hoge'; -- OK
>> SELECT pg_relpages(relname) FROM pg_class WHERE relname = 'hoge'; --
>> OK
>
> In the attached patch, I cleaned up three functions to have
> two types of arguments for each, text and regclass.
>
> pgstattuple(text)
> pgstattuple(regclass)
> pgstatindex(text)
> pgstatindex(regclass)
> pg_relpages(text)
> pg_relpages(regclass)
>
> I still think a regclass argument is more appropriate for passing
> relation/index name to a function than text-type, but having both
> arguments in each function seems to be a good choice at this moment,
> in terms of backward-compatibility.
>
> Docs needs to be updated if this change going to be applied.
Yes, please.
> Any comments?
'make installcheck' failed in my machine.
Do we need to remove pgstattuple--1.1.sql and create pgstattuple--1.1--1.2.sql?
+/* contrib/pgstattuple/pgstattuple--1.1.sql */
Typo: s/1.1/1.2
You seem to have forgotten to update pgstattuple.c.
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
