Re: pg_advisor schema proof of concept
От | Tom Lane |
---|---|
Тема | Re: pg_advisor schema proof of concept |
Дата | |
Msg-id | 18528.1080143578@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_advisor schema proof of concept (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: pg_advisor schema proof of concept
Re: pg_advisor schema proof of concept |
Список | pgsql-hackers |
Fabien COELHO <coelho@cri.ensmp.fr> writes: >>> (1) should it use pg_catalog.* or information_schema.*? >> >> Not sure portability is important, but using information_schema will >> presumably make it less likely that things will change between versions. > Another issue I found is that, although all the contents of > information_schema can be found in pg_catalog (as it derives from it!) not > all of pg_catalog may be found in information_schema... This is necessarily so, as the information_schema by definition covers only concepts standardized by the SQL spec. Since the SQL spec considers things like indexes to be implementation details, it is simply not possible for information_schema to tell you everything you want to know to give performance advice. >> If plpgsql works OK, I say stick with it. > Hmmm. I'm not very happy with plpgsql, I don't know where you are planning on going with this. If it's only to be a contrib tool, it's okay to depend on plpgsql. But we couldn't incorporate it into the base system because plpgsql isn't part of the base system. regards, tom lane
В списке pgsql-hackers по дате отправления: