Re: \d is not showing global(normal) table info if we createtemporary table with same name as global table - Mailing list pgsql-hackers

From Mahendra Singh Thalor
Subject Re: \d is not showing global(normal) table info if we createtemporary table with same name as global table
Date
Msg-id CAKYtNApjxOchnoqJByLEmXQVEgvK6kQ0L2JrJHC2U+GfPEFFkg@mail.gmail.com
Whole thread Raw
In response to Re: \d is not showing global(normal) table info if we create temporary table with same name as global table  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 3 Jan 2020 at 00:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Thu, Jan 2, 2020 at 12:59 PM Mahendra Singh <mahi6run@gmail.com> wrote:
> >> While reading code and doing some testing, I found that if we create a temporary table with same name as we
createda normal(global) table, then \d is showing only temporary table info. 
>
> > That's because the query that \d issues to the backend includes:
> >   AND pg_catalog.pg_table_is_visible(c.oid)
> > So I'd say it's not a bug, because that bit of SQL didn't get included
> > in the query by accident.
>
> It's also documented:
>
>     Whenever the pattern parameter is omitted completely, the \d commands
>     display all objects that are visible in the current schema search path
>     — this is equivalent to using * as the pattern. (An object is said to
>     be visible if its containing schema is in the search path and no
>     object of the same kind and name appears earlier in the search
>     path. This is equivalent to the statement that the object can be
>     referenced by name without explicit schema qualification.) To see all
>     objects in the database regardless of visibility, use *.* as the
>     pattern.
>
> Perhaps that's not clear enough, but the behavior is certainly as-intended.
>
>                         regards, tom lane

Thanks Robert  and Tom  for quick detailed response.

--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Add basic TAP tests for psql's tab-completion logic.
Next
From: Vik Fearing
Date:
Subject: Re: Greatest Common Divisor