CVSROOT:	/cvsroot
Module name:	pgsql-server
Changes by:	davec@postgresql.org	03/01/23 13:49:22

Modified files:
	src/interfaces/jdbc/org/postgresql/jdbc2: 
	                                          AbstractJdbc2ResultSet.java 

Log message:
	added fix from Joel Hock to get the inserted row into the current buffer


Thu, 23 Jan 2003 13:49:23 -0500 (EST)
davec@postgresql.org (Dave Cramer)
pgsql-server/src/interfaces/jdbc/org/postgresq ...
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       | dba
 term_029   | schedule_preceptor     | table    | f       | dba
 term_029   | schedule_preceptor_seq | sequence | f       | dba
 term_029   | schedule_seq           | sequence | f       | dba
 term_029   | schedule_student       | table    | f       | dba
 term_029   | schedule_student_seq   | sequence | f       | dba
 term_032   | schedule               | table    | t       | dba
 term_032   | schedule_preceptor     | table    | t       | dba
 term_032   | schedule_preceptor_seq | sequence | t       | dba
 term_032   | schedule_seq           | sequence | t       | dba
 term_032   | schedule_student       | table    | t       | dba
 term_032   | schedule_student_seq   | sequence | t       | dba

-- 
//========================================================\\
||  D. Hageman                    <dhageman@dracken.com>  ||
\\========================================================//
Thu, 23 Jan 2003 14:45:30 -0600 (CST)
"D. Hageman" <dhageman@dracken.com>
[PATCH] psql visibility clarification patch
"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

Fri, 24 Jan 2003 00:33:00 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] psql visibility clarification patch 
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

Fri, 24 Jan 2003 08:32:13 -0600
"John Liu" <johnl@emrx.com>
poor performance of subquery in psql 
"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

Wed, 29 Jan 2003 02:33:01 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: poor performance of subquery in psql 