Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
