Re: psql \d commands and information_schema

Greg Stark <stark(at)enterprisedb(dot)com> writes:
> On Wed, Apr 8, 2009 at 3:49 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> We already had a huge discussion over 'S' and I think we did as good as
>> we can. I think we risk overcomplicating the API by adding U, but we
>> can revisit this in 8.5 once we get more feedback from users.

> I think we'll need to take stock before 8.4 actually. Tom's pointed
> out a whole pile of problems with the current approach and I'm
> becoming convinced he's right. I know I was one of the proponents of
> the change but I didn't realize how bad the problems were.

> As I understand his proposal is that \df with no pattern could list
> all user functions but \df <pattern> should always follow the
> search_path and show the same functions that would actually be called.

Uh, that change got applied last week ...
http://archives.postgresql.org/pgsql-committers/2009-04/msg00014.php

> One possibility for reducing clutter would be moving a whole slew of
> the system functions which are never intended for users to call
> explicitly to a different schema which isn't implicitly added to
> search_path. That would at least get all the RI functions, bt procs,
> maybe even the operator functions out of the way.

Perhaps, but is it really important? I haven't noticed that those
things were cluttering my \df searches anyway.

BTW, I hesitate to mention this and perhaps upset a fragile consensus,
but should we remove the special-case code in \df that tries to hide I/O
functions by excluding functions that take or return cstring? I think
that its value has largely disappeared given the new overall behavior.

regards, tom lane