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?
Thanks,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
