Обсуждение: [PATCH] psql visibility clarification patch

Attached is a patch that I would like to submit for discussion.  
The goal of this patch is a solution to the issue that I found concerning 
table visibility.  The problem with the way psql currently lists tables in 
a database is that it limits it to only the tables currently in the search 
path.  If it isn't visible, then you will never see the table.  This can 
cause problems for a person that is trying to learn a database for the 
first time or something along those lines unless they are familiar with 
the pg_catalog.  I think a better solution to handling the issue of 
visibility is shown below.  It will list all of the tables of the database 
and show another column to give indication of the visibility of the table.  

eecs=> \d                       List of relations  Schema   |          Name          |   Type   | Visible | Owner 
------------+------------------------+----------+---------+-------term_029   | schedule               | table    | f
  | dbaterm_029   | schedule_preceptor     | table    | f       | dbaterm_029   | schedule_preceptor_seq | sequence | f
     | dbaterm_029   | schedule_seq           | sequence | f       | dbaterm_029   | schedule_student       | table
|f       | dbaterm_029   | schedule_student_seq   | sequence | f       | dbaterm_032   | schedule               | table
  | t       | dbaterm_032   | schedule_preceptor     | table    | t       | dbaterm_032   | schedule_preceptor_seq |
sequence| t       | dbaterm_032   | schedule_seq           | sequence | t       | dbaterm_032   | schedule_student
| table    | t       | dbaterm_032   | schedule_student_seq   | sequence | t       | dba
 

-- 
//========================================================\\
||  D. Hageman                    <dhageman@dracken.com>  ||
\\========================================================//

"D. Hageman" <dhageman@dracken.com> writes:
> The goal of this patch is a solution to the issue that I found concerning 
> table visibility.  The problem with the way psql currently lists tables in 
> a database is that it limits it to only the tables currently in the search 
> path.

That's the intended behavior.  I don't think that "\dt foo" should show
any tables other than the same "foo" you'd get from an unqualified
reference to "foo".  If you want to know about foos that are not in
your search path, you can do "\dt *.foo".

Your proposed patch essentially eliminates the distinction between
\dt foo and \dt *.foo.  This doesn't seem like a step forward to me.
Perhaps what's really needed is a documentation patch explaining when
to use each?
        regards, tom lane

1. the following query is so slow, after 12 hours, 
I kill it -
delete from doc where cdi in (select cdi from doc_b1);
doc_b1 records = 40000
doc records = 5000000
cdi are indexed in both table.

2. I rewrite the above task in plpgsql, it
takes 10 secs to finish. 

why psql subquery is not smarter enough to use
indexes if obviously?

johnl

"John Liu" <johnl@emrx.com> writes:
> why psql subquery is not smarter enough to use
> indexes if obviously?

IN is smarter as of CVS tip.
        regards, tom lane