> > Because that's what I originally did and you shot it down as a bad
> > patch because you thought it wasn't in PostgreSQL's interest to filter
> > what we showed the user.
>
> I'm still unconvinced on that, actually ... but it beats the heck out of
> filtering everything not in your search path ...
Well, for the sake of clarifying your opinion, would you be in favor
of a set of rules for the information_schema.* views that would update
the pg_catalog.* tables, as the pg_catalog.* tables are an
implementation detail? That's going to the extreme, but where do you
see the middle ground in terms of simplifying a user experience and
hiding users from PostgreSQL's nuts and bolts?
Hiding pg_temp_* schemas seems like a good idea to me given temp
objects are visible in every schema and the path of a temp object is
subject to change... an overly diligent admin might try and hard code
in the schema of a temp object only to find that path not portable,
thus exposing that information would strike me as a liability and not
an asset. And then there's the idea of providing an admin-mode that
exposes all of the implementation details (Hint, hint. I'd do the leg
work on this if it wouldn't be categorically dropped at the front
door). Anyway, I know we've covered this in the archives so I'll drop
it.
As an FYI, I just updated to an Opteron box and have been enjoying a
little over 1500 temp schemas and a paltry ~30 non-temp schemas.
Getting this patch in would be oh so very appreciated as maintaining
local copies of psql(1) is getting old. I know it's not my decision
to make, but I'd settle and shut up if there was an indirect proof for
why this shouldn't be included as a patch (ie, a valid usecase for an
admin or programmer who would need to see any or all of the pg_temp_*
schemas without using that data to extract more bits from the
pg_catalogs. If they know how to go through the catalogs, why do they
need \dn to display the temp schemas?).
As always, --Sean
--
Sean Chittenden
