19

Version 8.4.16 (no choice in version).

I log into my db as follows:

psql -d JRuser

The resulting prompt is:

JRuser=>

I do \d or \dt expecting to see a list of all the relations in schema 'translate'

No relations found.

But I can select from any of the tables in the schema without any issues. For example:

select * from translate.storage; --works fine

I have ensured that the access privileges are correct for JRuser by doing \dn+:

                                 List of schemas
        Name        |  Owner   |  Access privileges   |           Description  
translate           | JRuser   | JRuser=UC/JRuser     | 
                               : postgres=UC/JRuser

Why can't I see the tables in the translate schema?

Erwin Brandstetter
  • 605,456
  • 145
  • 1,078
  • 1,228
lostinthebits
  • 661
  • 2
  • 11
  • 24
  • 2
    I think you need to use `\dt translation.*` –  Jul 10 '13 at 18:25
  • I can certainly do that but up until today I've been able to do just \d or \d without any qualifier. I didn't change any configuration settings so I am puzzled. – lostinthebits Jul 10 '13 at 18:28

1 Answers1

23

\d in psql only shows visible tables, i.e. in your search_path.

Try and see:

SHOW search_path;
SET search_path= translate;
\d

The setting for your session has probably been changed somehow. There are multiple ways to do that:

Related later question on dba.SE:

Community
  • 1
  • 1
Erwin Brandstetter
  • 605,456
  • 145
  • 1,078
  • 1,228
  • Can a search_path variable contain multiple schemas if a user wants to be able to show tables on all schemas? – lostinthebits Jul 10 '13 at 18:57
  • 1
    @lostinthebits: see here: http://www.postgresql.org/docs/8.4/static/sql-set.html#AEN65998 –  Jul 10 '13 at 21:58
  • 1
    Changing the search_path is tedious but necessary for the shell commands to find relations of a new database. Here's a more detailed answer on what the value of the path needs to be: http://stackoverflow.com/questions/9067335/how-to-create-table-inside-specific-schema-by-default-in-postgres/9067777#9067777 – sdailey Sep 22 '13 at 11:57