Re: leaky views, yet again
От | Robert Haas |
---|---|
Тема | Re: leaky views, yet again |
Дата | |
Msg-id | AANLkTinqFy77sjwY+BDotVYSYNvYV-+a0fJod=9BPDNK@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: leaky views, yet again (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Ответы |
Re: leaky views, yet again
|
Список | pgsql-hackers |
2010/10/5 KaiGai Kohei <kaigai@ak.jp.nec.com>: >> The term "built-in functions" means functions written in INTERNAL language >> here. But we also have SQL functions by default. Some of them are just a >> wrapper to internal functions. I'm not sure the checking of INTERNAL language >> is the best way for the purpose. Did you compare it with other methods? >> For example, "oid< FirstNormalObjectId" looks workable for me. >> > Hmm. I'm not sure they can be used for index-scans. If these operators are not > corresponding to index-scans, I want to keep the logic to check INTERNAL language, > because these have obviously no side effects (= not leakable anything). I think the idea that all internal operators are safe has been thoroughly discredited already. > Hmm. It might be better than ad-hoc enhancement of StdRdOptions. > BTW, which is more preference to store the flag of security view: > reloption of the view or a new bool variable in the pg_class? > > I tried to store this flag within reloptions to minimize the patch > size, but it seems to me reloption support for views makes the patch > size larger in the result. I think a boolean in pg_class is the way to go. Is there a padding byte we can steal, to avoid making the fixed-size portion larger? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: