Re: pg_class.relistemp

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_class.relistemp
Дата
Msg-id 2601.1310748113@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_class.relistemp  ("David E. Wheeler" <david@kineticode.com>)
Ответы Re: pg_class.relistemp
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: pg_class.relistemp
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: SSI error messages