I would settle for just following the search path as set by the user. If you explicitly include pg_catalog in the search path, then you should see those settings.
If you do not explicitly include pg_catalog on the search_path, then it should not find those items. Right now pg_catalog sneaks its way onto the search_path for everybody. That is fine for execution but information listing like this should probably ignore those additions. On Thu, Jan 15, 2009 at 11:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Bruce Momjian <br...@momjian.us> writes: > > Tom Lane wrote: > >> I think this falls in the category of "be careful what you wish for, > >> you might get it". It is now blindingly obvious that the folks asking > >> for that had not actually lived with the behavior for any period of > >> time. > > > I got several emails thanking me for applying the patch, so there is > > clearly user-demand for 'S'. > > Were any of them from people who had actually *used* the patch for more > than five minutes? I think this is clearly a case of allowing abstract > consistency considerations to override usability. > > The real problem here is that the 'S' suffix for \dt is a bad precedent > for everything else. If you want consistency then we need to change > that end of things. I think that the idea of a switch to omit system > objects, rather than include them, might work. > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
