Question

I created a temp table in my PostgreSQL DB using the following query

SELECT * INTO TEMP TABLE tempdata FROM data WHERE id=2004;

Now I want to create a backup of this temp table tempdata.
So i use the following command line execution

"C:\Program Files\PostgreSQL\9.0\bin\pg_dump.exe" -F t -a -U my_admin -t tempdata myDB >"e:\mydump.backup"  

I get a message saying

pg_dump: No matching tables were found  

Is it possible to create a dump of temp tables?
Am I doing it correctly?

P.S. : I would also want to restore the same.I don’t want to use any extra components.

TIA.

Answer 1

I don’t think you’ll be able to use pg_dump for that temporary table. The problem is that temporary tables only exist within the session where they were created:

PostgreSQL instead requires each session to issue its own CREATE TEMPORARY TABLE command for each temporary table to be used. This allows different sessions to use the same temporary table name for different purposes, whereas the standard’s approach constrains all instances of a given temporary table name to have the same table structure.

So you’d create the temporary table in one session but pg_dump would be using a different session that doesn’t have your temporary table.

However, COPY should work:

COPY moves data between PostgreSQL tables and standard file-system files.

but you’ll either be copying the data to the standard output or a file on the database server (which requires superuser access):

COPY with a file name instructs the PostgreSQL server to directly read from or write to a file. The file must be accessible to the server and the name must be specified from the viewpoint of the server.
[…]
COPY naming a file is only allowed to database superusers, since it allows reading or writing any file that the server has privileges to access.

So using COPY to dump the temporary table straight to a file might not be an option. You can COPY to the standard output though but how well that will work depends on how you’re accessing the database.

You might have better luck if you didn’t use temporary tables. You would, of course, have to manage unique table names to avoid conflicts with other sessions and you’d have to take care to ensure that your non-temporary temporary tables were dropped when you were done with them.