I have a database where I'd created a copy of pg_class in public.
pgAdmin shows that the table exists, but \d doesn't. This is because of
how pg_table_is_visible works, specifically this comment:

/*
* If it is in the path, it might still not be visible; it could be
* hidden by another relation of the same name earlier in the path. So
* we must do a slow check for conflicting relations.
*/

While this is correct on a per-relation level, I'm thinking that it's
not what we'd really like to have happen in psql. What I'd like \d to do
is show me everything in any schema that's in my search_path, even if
there's something higher in the search_path that would over-ride it.
ISTM that's what most people would expect out of \d.

If no one objects I'll come up with a patch for this.
--
Decibel!, aka Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Search Discussions

  • Tom Lane at Sep 5, 2007 at 7:28 pm

    Decibel! <decibel@decibel.org> writes:
    While this is correct on a per-relation level, I'm thinking that it's
    not what we'd really like to have happen in psql. What I'd like \d to do
    is show me everything in any schema that's in my search_path, even if
    there's something higher in the search_path that would over-ride it.
    ISTM that's what most people would expect out of \d.
    I don't agree with that reasoning in the least, particularly not if you
    intend to "fix" it by redefining pg_table_is_visible() ...

    What will happen if we change \d to work that way is that it will show
    you a table, and you'll try to access it, and you'll get the wrong table
    because the access will go to the one that really is visible.

    regards, tom lane
  • Decibel! at Sep 7, 2007 at 8:47 pm

    On Wed, Sep 05, 2007 at 03:27:50PM -0400, Tom Lane wrote:
    Decibel! <decibel@decibel.org> writes:
    While this is correct on a per-relation level, I'm thinking that it's
    not what we'd really like to have happen in psql. What I'd like \d to do
    is show me everything in any schema that's in my search_path, even if
    there's something higher in the search_path that would over-ride it.
    ISTM that's what most people would expect out of \d.
    I don't agree with that reasoning in the least, particularly not if you
    intend to "fix" it by redefining pg_table_is_visible() ...
    No, pg_table_is_visible is correct as-is.
    What will happen if we change \d to work that way is that it will show
    you a table, and you'll try to access it, and you'll get the wrong table
    because the access will go to the one that really is visible.
    That's why I was suggesting that any table showing up in \d that in-fact
    wasn't visible be marked somehow, either with a separate field, or by
    sticking an * after it's name.

    This is confusing because when using \d you generally think in terms of
    what schemas are in your search path, not if an individual object has
    been superseded by something further up the chain.
    --
    Decibel!, aka Jim Nasby decibel@decibel.org
    EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 5, '07 at 4:24p
activeSep 7, '07 at 8:47p
posts3
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Decibel!: 2 posts Tom Lane: 1 post

People

Translate

site design / logo © 2022 Grokbase