On Tue, Aug 21, 2012 at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Aug 21, 2012 at 12:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I can work on it if you're still swamped. I think it is probably >>> fixable by treating the view options as attached to the _RETURN rule >>> instead of the base table in pg_dump's objects. (There is an ALTER VIEW >>> command to set the security option, no?) > >> Yep, we need to emit: > >> ALTER VIEW whatever SET (security_barrier = true); > >> ...after creating the rule that transforms it into a view. I spent a >> little time looking at this before lunch and it seems pretty >> straightforward to exclude the options from the dump of the table: I >> think we can just have repairViewRuleMultiLoop() to clear ((TableInfo >> *) table)->reloptions. > >> However, that by itself would result in them not getting dumped >> anywhere, so then I guess we need to add a reloptions field to >> RuleInfo. repairViewMultiLoop() can then detach the options from the >> TableInfo object and attach them to the RuleInfo object. Then we can >> adjust dumpRule() to print an ALTER VIEW command for any attached >> reloptions. That seems pretty grotty because it kind of flies in the >> face of the idea that the table and the rule are separate objects, but >> I don't have a better idea. > > Yeah, that sounds about right. You want to do it, or shall I?
If you don't mind dealing with it, that's great. If you'd prefer that I cleaned up my own mess, I'll take care of it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
