CREATE TEMPORARY TABLE .. ON COMMIT DROP question
am 19.11.2004 15:05:47 von abief_ag_-postgresql
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
am 19.11.2004 16:08:15 von tgl
"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
am 19.11.2004 16:54:50 von abief_ag_-postgresql
--- 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