On Jul 14, 2011, at 5:13 PM, "David E. Wheeler" <da...@kineticode.com> wrote: > On Jul 14, 2011, at 3:05 PM, Tom Lane wrote: > >> Josh Berkus <j...@agliodbs.com> writes: >>>> There are a ton of >>>> things that change with each release, and all we do by putting in >>>> hacks for backwards compatibility is add bloat that needs to be >>>> maintained, and encourage vendors to be lazy. >> >>> I don't agree that having comprehensive system views with multi-version >>> stability would be a "hack". >> >> If we had that, it wouldn't be a hack. > > Is that an endorsement for adding such a feature? > >> Putting in a hack to cover the >> specific case of relistemp, on the other hand, is just a hack. > > Sure. > >> The real question here, IMO, is "how many applications are there that >> really need to know about temporary relations, but have no interest in >> the related feature of unlogged relations?". Because only such apps >> would be served by a compatibility hack for this. An app that thinks it >> knows the semantics of relistemp, and isn't updated to grok unlogged >> tables, may be worse than broken --- it may be silently incorrect. > > So pgTAP creates temporary tables to store result sets so that it can then > compare the results of two queries. The function in question was getting a > list of columns in such a temporary table in order to make sure that the > types were the same between two such tables before comparing results. It > checked relistemp to make sure it was looking at the temp table rather than > some other table that might happen to have the same name. > > So now the query looks like this: > > SELECT pg_catalog.format_type(a.atttypid, a.atttypmod) > FROM pg_catalog.pg_attribute a > JOIN pg_catalog.pg_class c ON a.attrelid = c.oid > WHERE c.relname = $1 > -- AND c.relistemp -- 8.3-9.0 > AND c.relpersistence = 't' -- 9.1 > AND attnum > 0 > AND NOT attisdropped > ORDER BY attnum > > Is that all I need to do, or is there something else I should be aware of > with regard to unlogged tables?
Probably not, in this case. Just a thought: maybe you could rewrite the query to check whether the namespace name starts with pg_temp. Maybe that would be version-independent... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers