Satoshi Nagayasu <snaga@uptime.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
