Re: Making temp tables' toast tables be temp

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Making temp tables' toast tables be temp
Date: 2007-07-25 16:21:54
Message-ID: 20574.1185380514@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> So I'm thinking it might be time to fix this. After checking the
>> code, it seems like it'd be a reasonably small patch if we establish
>> a convention that toast tables for a temp schema pg_temp_nnn are
>> kept in an associated dedicated schema, named something like
>> pg_temp_nnn_toast or pg_toast_temp_nnn. Then functions like
>> isOtherTempNamespace() could still recognize these tables as temp.
>> It'd mean a bit more clutter in pg_namespace though.

> Why not just in the same pg_temp namespace?

Well, there's a risk of collisions with user table names; not a big
risk maybe but not nil. Also, that would be in the search path,
making the toast tables "visible" so that they'd be displayed by
things like psql's \dt. Keeping toast tables in their own schema
that's not in the path has worked well for us since 7.3, and I don't
want to give it up.

Any thoughts about which naming convention to use? pg_temp_nnn_toast or
pg_temp_toast_nnn would emphasize the "temp-ness" while pg_toast_temp_nnn
would emphasize the "toast-ness". It'd be roughly the same as far as
the backend is concerned (since it mostly deals with OIDs not names
anyway), and I'm not too sure whether any client-side code would care
or what its preference would be.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2007-07-25 16:53:13 Re: Machine available for community use
Previous Message Gregory Stark 2007-07-25 16:13:15 Re: Making temp tables' toast tables be temp