Satoshi Nagayasu <sn...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers