Re: pg_class.relistemp

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jim Nasby <jim(at)nasby(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_class.relistemp
Date: 2011-07-17 02:31:39
Message-ID: 96E7B156-D8A4-429E-8D27-E226AE210DCD@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 some period of time.

Best,

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-07-17 03:00:30 Re: Re: patch review : Add ability to constrain backend temporary file space
Previous Message Robert Haas 2011-07-17 02:16:38 Re: pg_class.relistemp