Re: pg_class.relistemp - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: pg_class.relistemp
Date
Msg-id 96E7B156-D8A4-429E-8D27-E226AE210DCD@kineticode.com
Whole thread Raw
In response to Re: pg_class.relistemp  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Jul 16, 2011, at 7:16 PM, Robert Haas wrote:

> 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.

Well I think it would continue to work exactly as it has in the past. And if one needed to know other information about
the*type* of temp table, well then one would have to use relpersistence. 

The idea is not to try to make it adapt to future changes. The idea is to try to preserve the previous behavior for
someperiod of time. 

Best,

David




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_class.relistemp
Next
From: Tom Lane
Date:
Subject: Re: Re: patch review : Add ability to constrain backend temporary file space