Re: pg_class.relistemp - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_class.relistemp
Date
Msg-id 2601.1310748113@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_class.relistemp  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: pg_class.relistemp
List pgsql-hackers
"David E. Wheeler" <david@kineticode.com> writes:
> So pgTAP creates temporary tables to store result sets so that it can then compare the results of two queries. The
functionin question was getting a list of columns in such a temporary table in order to make sure that the types were
thesame between two such tables before comparing results. It checked relistemp to make sure it was looking at the temp
tablerather than some other table that might happen to have the same name.
 

Well, actually, that code flat out doesn't work, so whether relistemp is
available in 9.1 is the least of your problems.  Consider what would
happen if two concurrent sessions did this with the same temp table
name.

How about doing this instead?
       SELECT pg_catalog.format_type(a.atttypid, a.atttypmod)         FROM pg_catalog.pg_attribute a         JOIN
pg_catalog.pg_classc ON a.attrelid = c.oid        WHERE c.oid = 'pg_temp.tablenamehere'::pg_catalog.regclass
ANDattnum > 0          AND NOT attisdropped        ORDER BY attnum
 

This would only work in releases that know the pg_temp abbreviation,
which includes any minor release later than March 2007.  But since
relistemp doesn't even exist before 8.4 (released in 2009), that's still
more backwards-portable than what you've got.  You could also just do
'tablenamehere'::pg_catalog.regclass and trust that the user didn't move
pg_temp to the back of the search path.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pg_class.relistemp
Next
From: "Kevin Grittner"
Date:
Subject: Re: SSI error messages