"Greg Sabino Mullane" <greg@turnstep.com> writes:
>> It also changes the test for system objects to key off the namespace
>> name starting with 'pg_' instead of the object name.
> I *think* you want to make it more specific and look for items in the
> pg_catalog namespace, since this is where the system objects now live.
Well, you definitely want to ignore pg_toast, and I'd think you want to
ignore pg_temp_NNN (except perhaps your own), so Joe's approach is more
nearly right.
> My own patch is pretty much complete - anyone have other feedback on it?
I had looked at it and decided it wasn't ready for prime time, though
I must confess I don't recall why. I thought you were off doing more
work on it.
> It appears as though current_schemas() is not quite finished - any
> ideas on when this will be done? Once it accepts a boolean arg
It's done that for some time. However, "nsp in current_schemas" isn't
going to solve psql's problem anyway, since it ignores the fundamental
issue of visibility: just because an object is in your search path does
not mean you can see it. It might be masked by a similarly-named object
earlier in the path.
What I suspect we will need to do is export namespace.c's RelationIsVisible
and friends as SQL functions. Then psql's commands could include
"where relation_is_visible(pg_class.oid)" to filter the output.
This still begs the question of exactly how psql wildcard patterns
should interact with schemas. Does '.' become a special (and not
wildcardable) character in such patterns? Do we allow wildcards
in the schema part? If we do, then "\d *.*" would be different
from "\d *" (the former shows everything, the latter only what is
visible in your search path). I'm not sure if this is useful or
merely confusing.
regards, tom lane
