Обсуждение: TEMP table code

I am attaching a file containing changes needed for adding temp tables
to the backend code.  This is not a complete patch because I am adding
new files and stuff.  It is attached just for people to review.

The basic question is whether this is the proper way to do temp tables.
This implementation never adds the table to the system tables like
pg_class and pg_attribute.  It does all temp table work by mapping the
user table names to system-generated unique table names using the cache
lookup code.  Fortunately because of the mega-patch from August, almost
all system table access is done through the cache.  Of course, a table
scan of pg_class will not show the temp table because it is not really
in pg_class, just in the cache, but there does not seem to be many cases
where this is a bad thing.

I still need to run some more tests and add a few more features, but you
get the idea.  I hope to apply the patch tomorrow or Saturday.

The only other way I can think of doing temp tables is to actually
insert into the system tables, and have some flag that makes those rows
only visible to the single backend that created it.  We would also have
to add a new pg_class column that contained the temp name, and modify
pg_class so it could have duplicate table names as long as the temp name
was unique.  This seemed very unmodular, and would add more complexity
to the heap tuple tuple visibility code.

Here is a sample of what it does:

    #$ sql test
    Welcome to the POSTGRESQL interactive sql monitor:
        test=> select * from test;
        ERROR:  test: Table does not exist.
        test=> create temp table test (x int);
        CREATE
        test=> insert into test values (3);
        INSERT 19745 1
        test=> \q
    #$ sql test
    Welcome to the POSTGRESQL interactive sql monitor:
        test=> select * from test;
        ERROR:  test: Table does not exist.
        test=>

In this example, I create a non-temp table, then mask that with a temp
table, then destroy them both:

    #$ sql test
    Welcome to the POSTGRESQL interactive sql monitor:
        test=> create table test (x int);
        CREATE
        test=> create temp table test (x int);
        CREATE
        test=> create temp table test (x int);
        ERROR:  test relation already exists
        test=> drop table test;
        DROP
        test=> drop table test;
        DROP
        test=>

--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

> The basic question is whether this is the proper way to do temp 
> tables.

I haven't looked at the patches, but fwiw I would have tried it about
the same way. No need to touch pg_class if the info is
session-specific...
                     - Tom

> > The basic question is whether this is the proper way to do temp 
> > tables.
> 
> I haven't looked at the patches, but fwiw I would have tried it about
> the same way. No need to touch pg_class if the info is
> session-specific...

Yes, my feeling is that the code is complicated enough without having
the temp table stuff adding complexity.  What I did is that a cache
lookup returns a fake pg_class tuple.  The only code changes are a few
function calls in the cache routines to insert my fake tuples, and some
code in the heap_create_with_catalog/heap_create/heap_destroy code to
create temp tables with unique names.  A new istemp flag in a few
structuers.  The rest of the code is untouched.


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026