Re: behavior of \dt and schemas

Especially as I just tested setting the search_path to both schemas and
then created another new and uniquely named table under the second schema
so this time \dt showed just the duplicated tables from the first schema,
but also showed the uniquely named table from the second. That latter part
would have been my expected behavior. I expected you'd all disagree with
me, but it still seems a bit non-intuitive to me.

On Fri, Jan 20, 2017 at 11:09 AM, John Scalia <jayknowsunix(at)gmail(dot)com>
wrote:

> Understood, but I would have suspected that the search_path value would
> have been expanded to report all the tables visible under each schema, and
> not mask any. It just surprised me a little.
>
> On Fri, Jan 20, 2017 at 10:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
>> > On Friday, January 20, 2017, John Scalia <jayknowsunix(at)gmail(dot)com>
>> wrote:
>> >> So, to me this is somewhat non-intuitive behavior, but maybe I'm all
>> wet
>> >> here. Shouldn't \dt report all the tables it can see with the
>> search_path
>> >> set to some value? And btw, this is was the behavior on 9.4.10, so if
>> it's
>> >> changed in more recent versions, I haven't tested there yet.
>>
>> > It shows the definition of the table you would be referencing if you
>> used
>> > that name in a query. This seems like a useful behavior.
>>
>> Right --- according to our normal terminology, b.mytable is *not* visible,
>> because it is masked by a.mytable being ahead of it in the search path.
>> You'd have to write a qualified name to get at b.mytable.
>>
>> You can write, eg, "\dt *.mytable" or "\dt *.*" if you would like it to
>> show tables that are not visible according to this rule. Without a
>> dot in the pattern, \dt shows only visible tables, ie only the ones
>> you could name without putting a dot in the name.
>>
>> regards, tom lane
>>
>
>