Re: Oddity with psql \d and pg_table_is_visible

From: Decibel! <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Oddity with psql \d and pg_table_is_visible
Date: 2007-09-07 20:46:42
Message-ID: 20070907204642.GU38801@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 05, 2007 at 03:27:50PM -0400, Tom Lane wrote:
> Decibel! <decibel(at)decibel(dot)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(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Avery Payne 2007-09-07 20:52:04 A Silly Idea for Vertically-Oriented Databases
Previous Message Tom Lane 2007-09-07 19:59:42 Re: Low hanging fruit in lazy-XID-assignment patch?