Re: leaky views, yet again
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: Itagaki Takahiro <itagaki.takahiro@gmail.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, KaiGai Kohei <kaigai@kaigai.gr.jp>, pgsql-hackers@postgresql.org
Date: 2010-10-05T14:16:10Z
Lists: 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