On Sat, Apr 27, 2013 at 3:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 1. The matviews mess. Changing that will force initdb, more than
>>> likely, so we need it resolved before beta1.
>
>> I would like to rip out the whole notion of whether a materialized
>> view is scannable and am happy to do that on Monday if you're willing
>> to sit still for it.
>
> That would actually be my druthers too; while I see that we're going to
> want such a concept eventually, I'm not convinced that the current
> feature is a reasonable (and upward-compatible) subset of what we'll
> want later. However, when I proposed doing that earlier, Kevin
> complained pretty strenuously. I'm willing to yield on the point,
> as long as the implementation doesn't make use of storage-file size
> to represent scannability.
>
>> I think that's better than failing to support
>> unlogged relations, and I'm confident that the decision to put the
>> scannability flag in pg_class rather than the backing file is dead
>> wrong. At the same time, I *also* agree that using the file size as a
>> flag is untenable.
>
> Um, wait, it's *not* in pg_class now, and what I was about to do was
> go put it there. Is there a typo in the above para, or are you saying
> you don't like either approach? If the latter, what concept have you
> got for an eventual implementation?
If we're going to have it at all, I'd like to make it a flag in the
page header on page 0, or maybe have a dedicated metapage that stores
that detail, and perhaps other things.
But really, I'd rather not have it at all.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company