Re: review: FDW API

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Feb 18, 2011 at 10:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The main downside of that is that relation relkinds would have
>> to become fixed (because there would be no practical way of updating
>> RTEs in stored rules), which means the "convert relation to view" hack
>> would have to go away. Offhand I think no one cares about that anymore,
>> but ...

> That actually sounds like a possible problem, because it's possible to
> create views with circular dependencies using CORV, and they won't
> dump-and-reload properly without that hack. It's not a particularly
> useful thing to do, of course, and I think we could reengineer pg_dump
> to not need the hack even if someone does do it, but that sounds like
> more work than we want to tackle right now.

Urgh. That's problematic, because even if we changed pg_dump (which
would not be that hard I think), we'd still have to cope with dump files
emitted by existing versions of pg_dump. The time constant before that
stops being an issue is measured in years. I'm not at all sure whether
the circular dependency case is infrequent enough that we could get away
with saying "tough luck" to people who hit the case.

[ thinks a bit ... ] But we can probably hack our way around that:
teach the rule rewriter to update relkind in any RTE it brings in from a
stored rule. We already do something similar in some other cases where
a stored parsetree node contains information that could become obsolete.

But that conclusion just makes it even clearer that fixing this
performance problem, if it even is real, should be a separate patch.

regards, tom lane