Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Apr 27, 2013 at 10:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Of the items on the 9.3 open-items page,
>> https://wiki.postgresql.org/wiki/PostgreSQL_9.3_Open_Items
>> there are at least three that seem like absolute drop-dead stop-ship issues:
> I completely agree. I think it's considerably premature to wrap a
> beta at this point. We haven't resolved the issue of what to do about
> accidental restores into pg_catalog either; nobody replied to my last
> email on that thread.
As far as that item goes, I agree it's must-fix, but I'm not sure it's
must-fix-before-beta.
>> 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?
regards, tom lane