Re: pg_class.relistemp

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_class.relistemp
Date: 2011-07-22 17:34:39
Message-ID: DE0DDEC7-2A01-4481-8332-144D7E748DC3@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-07-22 17:57:46 Re: Policy on pulling in code from other projects?
Previous Message Joshua D. Drake 2011-07-22 17:26:44 Re: Policy on pulling in code from other projects?