On Wed, Dec 15, 2010 at 4:06 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Sat, 2010-11-13 at 20:55 -0500, Robert Haas wrote: >> I think that would be a recipe for bugs. Look at the three new macros >> I introduced. If you keep relistemp around, then any code which >> relies on it is likely testing for one of those three things, or maybe >> even something subtly different from any of them, as in the cases >> where I needed to add a switch statement. The way I see it, this is >> ultimately a four-level hierarchy > > That argument isn't clear enough to avoid me agreeing so far with Tom > and Andrew that logged-ness is separate from temp-ness. As you say > though, it might be a recipe for bugs, so please explain a little more.
Sure. Most of the existing checks for rd_istemp were actually checking whether the relation required WAL-logging. If there's any third-party code out there that is checking rd_istemp, it likely also needs to be revised to check whether WAL-logging is needed, not whether the relation is temp. The way I've coded it, such code will fail to compile, and can be very easily fixed by substituting a call to RelationNeedsWAL() or RelationUsesLocalBuffers() or RelationUsesTempNamespace(), depending on which property the caller actually cares about. That's better than having the code compile, but then not work as expected. As of today, RelationNeedsWAL() always gives an answer which is directly opposite to the answer given by RelationUsesLocalBuffers() and RelationUsesTempNamespace(). But the main unlogged tables patch changes that. RelationNeedsWAL() will return true for permanent tables and false for unlogged and temp tables, while RelationUsesLocalBuffers() and RelationUsesTempNamespace() will return false for permanent and unlogged tables and true for temp tables. When and if we get global temporary tables, there will be a further split between RelationUsesLocalBuffers() and RelationUsesTempNamespace(). The former will return true for both global and local temporary tables, and the latter only for local temporary tables. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
