Re: pg_class.relistemp - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: pg_class.relistemp
Date
Msg-id DE0DDEC7-2A01-4481-8332-144D7E748DC3@kineticode.com
Whole thread Raw
In response to Re: pg_class.relistemp  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Jul 15, 2011, at 9:41 AM, Tom Lane wrote:

> 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.

Oh. Duh.

> How about doing this instead?
> 
>        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.oid = 'pg_temp.tablenamehere'::pg_catalog.regclass
>           AND attnum > 0
>           AND NOT attisdropped
>         ORDER BY attnum

I always forget that "$schema.$tablename"::regclass will work.

> 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.

Yeah, this is a much better solution. Many thanks, Tom, just what I needed.

Best,

David




pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Policy on pulling in code from other projects?
Next
From: Robert Haas
Date:
Subject: Re: Policy on pulling in code from other projects?