Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > How about if we add a UNION that does:
> > UNION
> > SELECT 'non-local temp schemas skipped', NULL
>
> I think showing that would only be appropriate if we actually *did* skip
> some. Finding that out would complicate the que
Sean Chittenden wrote:
> >
> > If you want to suppress *all* pg_temp_ schemas from the \dn listing,
> > that would be defensible maybe. I'd be inclined to say that
> > pg_toast should be hidden as well if that approach is taken, because
> > then you are basically saying that \dn is not the truth
Sean Chittenden wrote:
> > > If you see a pg_temp_* for every connection, that is a little
> > > overwhelming. pg_toast and stuff aren't really too bad. Is there
> > > any way to access your local temp schema in a way that doesn't
> > > show the others? Could we use backend_pid in the query and
> > If you see a pg_temp_* for every connection, that is a little
> > overwhelming. pg_toast and stuff aren't really too bad. Is there
> > any way to access your local temp schema in a way that doesn't
> > show the others? Could we use backend_pid in the query and show
> > them only their own?
>
Bruce Momjian wrote:
> Sean Chittenden wrote:
> > > I don't think that really answers my concern, since the sort of
> > > folks who are likely to get confused by not being able to see
> > > something that should be there are exactly the same ones who are not
> > > likely to have turned on a non-def
Sean Chittenden wrote:
> > I don't think that really answers my concern, since the sort of
> > folks who are likely to get confused by not being able to see
> > something that should be there are exactly the same ones who are not
> > likely to have turned on a non-default "power user" setting. If
> >> I dislike putting random restrictions on what the \d displays
> >> will show. We have done this in the past (eg, \df doesn't show
> >> things it thinks are I/O functions) and by and large it's been a
> >> mistake; I think it's created more confusion than it's prevented.
>
> > Hrm... psql's
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> I dislike putting random restrictions on what the \d displays will
>> show. We have done this in the past (eg, \df doesn't show things it
>> thinks are I/O functions) and by and large it's been a mistake; I
>> think it's created more confusion than it
> > Why wouldn't you want to hide pg_temp_*?
>
> So you could see your own temp tables, for instance.
>
> I dislike putting random restrictions on what the \d displays will
> show. We have done this in the past (eg, \df doesn't show things it
> thinks are I/O functions) and by and large it's bee
<[EMAIL PROTECTED]> writes:
> To follow-up then, if the temp schemas do not disappear, then over time
> what happens (as temp tables are instantiated during normal application
> usage), does the database end up with an ever-increasing number of these
> temp schemas?
No, you will never have more th
<[EMAIL PROTECTED]> writes:
> What's up with these miscellaneous schemas? Are they in fact related to
> the creation of temporary tables? Should they disappear when the session
> closes, as should the temporary table? If they continue persisting after
> the session closes, how do I get rid of them?
Whenever I create a temporary table, with something like
CREATE TEMPORARY TABLE temptable1 AS SELECT * FROM paid.ad_hoc_query;
New schemas appear, with names like "pg_temp_1". I guess the appearance
of these schemas with "temp" in the name indicates that they are
"temporary" schemas and related t
12 matches
Mail list logo
