pgsql-server/src/interfaces/jdbc/org/postgresq ...

Started by Nonamealmost 23 years ago5 messages
#1Noname
davec@postgresql.org

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

#2D. Hageman
dhageman@dracken.com
In reply to: Noname (#1)
1 attachment(s)
[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 | 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> ||
\\========================================================//

Attachments:

psql-visibility.patchtext/plain; charset=US-ASCII; name=psql-visibility.patchDownload
diff -ruN pgsql-server/src/bin/psql/describe.c pgsql-server.dhageman/src/bin/psql/describe.c
--- pgsql-server/src/bin/psql/describe.c	2003-01-07 14:56:06.000000000 -0600
+++ pgsql-server.dhageman/src/bin/psql/describe.c	2003-01-23 14:37:39.000000000 -0600
@@ -1274,10 +1274,11 @@
 					  "SELECT n.nspname as \"%s\",\n"
 					  "  c.relname as \"%s\",\n"
 					  "  CASE c.relkind WHEN 'r' THEN '%s' WHEN 'v' THEN '%s' WHEN 'i' THEN '%s' WHEN 'S' THEN '%s' WHEN 's' THEN '%s' END as \"%s\",\n"
+					  " pg_catalog.pg_table_is_visible(c.oid) as \"%s\",\n"
 					  "  u.usename as \"%s\"",
 					  _("Schema"), _("Name"),
 					  _("table"), _("view"), _("index"), _("sequence"),
-					  _("special"), _("Type"), _("Owner"));
+					  _("special"), _("Type"), _("Visible"), _("Owner"));
 
 	if (verbose)
 		appendPQExpBuffer(&buf,
@@ -1326,7 +1327,7 @@
 
 	processNamePattern(&buf, pattern, true, false,
 					   "n.nspname", "c.relname", NULL,
-					   "pg_catalog.pg_table_is_visible(c.oid)");
+					   NULL );
 
 	appendPQExpBuffer(&buf, "ORDER BY 1,2;");
 
#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: D. Hageman (#2)
Re: [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

#4John Liu
johnl@emrx.com
In reply to: Tom Lane (#3)
poor performance of subquery in psql

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

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: John Liu (#4)
Re: 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