Re: 9.2RC1 wraps this Thursday ...

On Tue, Aug 21, 2012 at 12:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Aug 21, 2012 at 10:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> * View options are problematic for pg_dump
>>>
>>> I had hoped those who created this problem were going to fix it, but
>>> given the lack of response I guess I'll have to.
>
>> This is my fault, but my hackers inbox got flooded and this got lost
>> in the shuffle. Sorry. I can probably devote some time to it today
>> if you don't want to be bothered with it. Do you have a sense of what
>> the right fix is?
>
> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company