X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 01CFC3A4B9C
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Fri, 19 Nov 2004 15:55:04 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 51307-06
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Fri, 19 Nov 2004 15:54:48 +0000 (GMT)
Received: from web13903.mail.yahoo.com (web13903.mail.yahoo.com
	[216.136.175.29])
	by svr1.postgresql.org (Postfix) with SMTP id 607D73A4B5B
	for <pgsql-sql@postgresql.org>; Fri, 19 Nov 2004 15:54:51 +0000 (GMT)
Received: (qmail 21059 invoked by uid 60001); 19 Nov 2004 15:54:51 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	b=m73tkU5zUSwQgKZAylNKOU85QFule8coLm+PoWh0nTIFgBaKVynSj/pt2wvyrpWLL6KkUh8AdPquVyRjMa7Ti8RrBG3PBCayXnIbpULKgDUCyj5472XV00Lh3XzS7/Nz8mSZJCmrXEfliuwBNgbEzxj6606ebYaqEufogM+Iytw=
	;
Message-ID: <20041119155450.21057.qmail@web13903.mail.yahoo.com>
Received: from [80.67.100.162] by web13903.mail.yahoo.com via HTTP;
	Fri, 19 Nov 2004 07:54:50 PST
Date: Fri, 19 Nov 2004 07:54:50 -0800 (PST)
From: "Riccardo G. Facchini" <abief_ag_-postgresql@yahoo.com>
Reply-To: abief_ag_-postgresql@yahoo.com
Subject: Re: CREATE TEMPORARY TABLE .. ON COMMIT DROP question 
To: pgsql-sql@postgresql.org
In-Reply-To: <27902.1100876895@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests=
X-Spam-Level: 
X-Archive-Number: 200411/195
X-Sequence-Number: 19514


--- Tom Lane <__> wrote:

> "Riccardo G. Facchini" <abief_ag_-postgresql@yahoo.com> writes:
> > I'm trying to understand where the "[ ON COMMIT { PRESERVE ROWS |
> > DELETE ROWS | DROP } ]" is stored when defining a temporary table.
> 
> I don't believe it's stored anyplace visible :-(.  There's some
> private
> state in the memory of the backend that owns the table.  Look into
> commands/tablecmds.c.
> 
> 			regards, tom lane
> 
[..]

Thanks, I'm reading the code at this right moment.

I'm wandering if this is consistent... I mean, a temporary table finds
its way to the pg_class as any other table, so I'm able to retrieve a
lot of things regarding that particular table. Even if a temporary
table is something that's assumed to be built by my own session, I may
want to know if what I store there is eventually destroyed.

this would mean extending the pg_class definition and generating the
associated code... not a big job, but something that may not be done
lightly.

I'm writing a set of utilities that run on pure plpgsql that provide
info about the objects contained in the database, and I started with
one of those things that are not provided by the pg_xxx functions, the
table. My code is capable of rendering the code of a temporary table,
but not capturing the info regarding the "ON COMMIT" part...

regards,

R.