(2010/10/05 23:16), Robert Haas wrote:
2010/10/5 KaiGai Kohei<kai...@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.
How can we distinguish an internal operator and others?
Because pg_operator does not have a property that we can use to
distinguish them, I tried to check function of the operators...
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?
OK, I'll add a boolean in pg_class. Perhaps, 'relissecview'?
Thanks
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
