Re: pg_class.relistemp

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: pg_class.relistemp
Дата
Msg-id 96E7B156-D8A4-429E-8D27-E226AE210DCD@kineticode.com
обсуждение исходный текст
Ответ на Re: pg_class.relistemp  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_class.relistemp
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: patch review : Add ability to constrain backend temporary file space