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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Satoshi Nagayasu <snaga(at)uptime(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fix pgstattuple/pgstatindex to use regclass-type as the argument
Date: 2013-03-03 22:32:17
Message-ID: 14217.1362349937@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Satoshi Nagayasu <snaga(at)uptime(dot)jp> writes:
> My goal is to allow specifying a relation/index with several
> expressions, 'relname', 'schemaname.relname' and oid in all
> pgstattuple functions. pgstatindex() does not accept oid so far.

> I have found that the backward-compatibility can be kept
> when the arguments (text and/or oid) are replaced with regclass
> type. regclass type seems to be more appropriate here.

I recall having looked at this with the same thought in mind, and
realizing that it's not really as simple as all that. Yes, it
will seem to be compatible in manual tests like

select * from pgstatindex('myschema.test_pkey');

but something like

select pgstattuple(relname) from pg_class where relkind = 'r';

will *not* work anymore, though it used to (modulo search path issues),
since there's no implicit cast from text to regclass.

Now of course, the above is very bad practice anyway --- it's much
safer, not to mention more efficient, to write

select pgstattuple(oid) from pg_class where relkind = 'r';

and that will still work if we replace the functions with a single
function taking regclass.

But ... historically, there hasn't been a pgstatindex(oid), and so
people may very well be using relname or perhaps oid::regclass::text
if they're using queries of this sort with pgstatindex.

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.

Also, you can't just modify pgstattuple--1.1.sql like that. You have
to create pgstattuple--1.2.sql and provide an upgrade script. It'd be a
good idea also to make sure that the module doesn't dump core if used
with the old SQL function definitions.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2013-03-03 22:47:50 Re: Materialized views WIP patch
Previous Message Josh Berkus 2013-03-03 21:35:03 Partial patch status update, 3/3/13