Re: pg_class.relistemp

On Fri, Jul 15, 2011 at 8:17 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> On Jul 13, 2011, at 2:23 PM, David E. Wheeler wrote:
>> Wasn't newsysviews supposed to deal with these sorts of issues? Why were they rejected?
>
> Unless they recently came up again and got rejected again; the original complaint was that some of their conventions didn't follow information_schema conventions. The community wanted that changed and that never happened.

I think, also, that the idea that newsysviews is going to fix all of
our problems is mostly wishful thinking. Let's suppose that we had a
system view over pg_class that kept around some variant of relistemp
even though it's gone from pg_class per se. Well, such a column would
probably be false for both unlogged and permanent tables and true for
temporary tables and David would be happy.

But what happens when and if we add global temporary tables? Now we
might very well decide to set the faux-relistemp to true for temporary
and global temporary tables (they do have "temporary" in the name,
after all!) and false for unlogged and permanent tables. Or we might
decide that the faux-relistemp should only be true for the kind of
temporary tables that we've always had, and false for these new global
temporary tables, perhaps on the theory that a global temporary table
is not really temporary at all, though its contents are. One of these
decisions would probably be right for David (and pgTap) and the other
would be wrong; and the decision that was right for pgTap might be
wrong for some other client. So instead of breaking pgTap we might
just quietly make it stop working correctly.

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