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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
