CREATE TEMPORARY TABLE .. ON COMMIT DROP question

Hi all,

I'm trying to understand where the "[ ON COMMIT { PRESERVE ROWS |
DELETE ROWS | DROP } ]" is stored when defining a temporary table.

whenever a table is created, a record in the pg_class is stored with
the info regarding the table, but I haven't been able to locate where
the info regarding these particular parameters is stored.

any suggestion?

regards,

Riccardo


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Re: CREATE TEMPORARY TABLE .. ON COMMIT DROP question

"Riccardo G. Facchini" 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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: CREATE TEMPORARY TABLE .. ON COMMIT DROP question

--- Tom Lane <__> wrote:

> "Riccardo G. Facchini" 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.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match