show casts and conversions in psql (2nd try)

Started by Christopher Kings-Lynneabout 23 years ago25 messages
#1Christopher Kings-Lynne
chriskl@familyhealth.com.au
1 attachment(s)

(Doh! Forgot to attach first time.)

This partially nails this TODO item:

* Add schema, cast, and conversion backslash commands to psql

I had to create a new publically available function,
pg_conversion_is_visible, as it seemed to be missing from the catalogs.
This required me to do no small amount of hacking around in namespace.c

I have updated the \? help and sgml docs.

\dc - list conversions [PATTERN]
\dC - list casts

I didn't support patterns with casts as there's nothing obvious to match
against.

I've tested it a fair bit and I can't see any problems. Feel free to do a
once over on my backend changes tho.

Chris

Attachments:

psql-patch.txttext/plain; name=psql-patch.txtDownload
? GNUmakefile
? config.log
? config.status
? configure.lineno
? ftipatch.txt
? guc.diff
? patch.txt
? psql-patch.txt
? contrib/fulltextindex2
? contrib/tsearch.tgz
? contrib/cube/cube.diff
? contrib/spi/.deps
? contrib/tsearch/.deps
? contrib/tsearch/libtsearch.so.0
? contrib/tsearch/parser.c
? contrib/tsearch/results
? contrib/tsearch/tsearch.sql
? src/Makefile.global
? src/backend/postgres
? src/backend/access/common/.deps
? src/backend/access/gist/.deps
? src/backend/access/hash/.deps
? src/backend/access/heap/.deps
? src/backend/access/index/.deps
? src/backend/access/nbtree/.deps
? src/backend/access/rtree/.deps
? src/backend/access/transam/.deps
? src/backend/bootstrap/.deps
? src/backend/catalog/.deps
? src/backend/catalog/postgres.bki
? src/backend/catalog/postgres.description
? src/backend/commands/.deps
? src/backend/executor/.deps
? src/backend/lib/.deps
? src/backend/libpq/.deps
? src/backend/main/.deps
? src/backend/nodes/.deps
? src/backend/optimizer/geqo/.deps
? src/backend/optimizer/path/.deps
? src/backend/optimizer/plan/.deps
? src/backend/optimizer/prep/.deps
? src/backend/optimizer/util/.deps
? src/backend/parser/.deps
? src/backend/port/.deps
? src/backend/postmaster/.deps
? src/backend/regex/.deps
? src/backend/rewrite/.deps
? src/backend/storage/buffer/.deps
? src/backend/storage/file/.deps
? src/backend/storage/freespace/.deps
? src/backend/storage/ipc/.deps
? src/backend/storage/large_object/.deps
? src/backend/storage/lmgr/.deps
? src/backend/storage/page/.deps
? src/backend/storage/smgr/.deps
? src/backend/tcop/.deps
? src/backend/utils/.deps
? src/backend/utils/adt/.deps
? src/backend/utils/cache/.deps
? src/backend/utils/error/.deps
? src/backend/utils/fmgr/.deps
? src/backend/utils/hash/.deps
? src/backend/utils/init/.deps
? src/backend/utils/mb/.deps
? src/backend/utils/mb/conversion_procs/conversion_create.sql
? src/backend/utils/mb/conversion_procs/ascii_and_mic/.deps
? src/backend/utils/mb/conversion_procs/ascii_and_mic/libascii_and_mic.so.0
? src/backend/utils/mb/conversion_procs/cyrillic_and_mic/.deps
? src/backend/utils/mb/conversion_procs/cyrillic_and_mic/libcyrillic_and_mic.so.0
? src/backend/utils/mb/conversion_procs/euc_cn_and_mic/.deps
? src/backend/utils/mb/conversion_procs/euc_cn_and_mic/libeuc_cn_and_mic.so.0
? src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/.deps
? src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/libeuc_jp_and_sjis.so.0
? src/backend/utils/mb/conversion_procs/euc_kr_and_mic/.deps
? src/backend/utils/mb/conversion_procs/euc_kr_and_mic/libeuc_kr_and_mic.so.0
? src/backend/utils/mb/conversion_procs/euc_tw_and_big5/.deps
? src/backend/utils/mb/conversion_procs/euc_tw_and_big5/libeuc_tw_and_big5.so.0
? src/backend/utils/mb/conversion_procs/latin2_and_win1250/.deps
? src/backend/utils/mb/conversion_procs/latin2_and_win1250/liblatin2_and_win1250.so.0
? src/backend/utils/mb/conversion_procs/latin_and_mic/.deps
? src/backend/utils/mb/conversion_procs/latin_and_mic/liblatin_and_mic.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_ascii/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_ascii/libutf8_and_ascii.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_big5/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_big5/libutf8_and_big5.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/libutf8_and_cyrillic.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_euc_cn/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_euc_cn/libutf8_and_euc_cn.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_euc_jp/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_euc_jp/libutf8_and_euc_jp.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_euc_kr/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_euc_kr/libutf8_and_euc_kr.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_euc_tw/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_euc_tw/libutf8_and_euc_tw.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_gb18030/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_gb18030/libutf8_and_gb18030.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_gbk/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_gbk/libutf8_and_gbk.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_iso8859/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_iso8859/libutf8_and_iso8859.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1/libutf8_and_iso8859_1.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_johab/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_johab/libutf8_and_johab.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_sjis/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_sjis/libutf8_and_sjis.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_tcvn/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_tcvn/libutf8_and_tcvn.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_uhc/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_uhc/libutf8_and_uhc.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_win1250/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_win1250/libutf8_and_win1250.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_win1256/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_win1256/libutf8_and_win1256.so.0
? src/backend/utils/mb/conversion_procs/utf8_and_win874/.deps
? src/backend/utils/mb/conversion_procs/utf8_and_win874/libutf8_and_win874.so.0
? src/backend/utils/misc/.deps
? src/backend/utils/mmgr/.deps
? src/backend/utils/sort/.deps
? src/backend/utils/time/.deps
? src/bin/initdb/initdb
? src/bin/initlocation/initlocation
? src/bin/ipcclean/ipcclean
? src/bin/pg_config/pg_config
? src/bin/pg_controldata/.deps
? src/bin/pg_controldata/pg_controldata
? src/bin/pg_ctl/pg_ctl
? src/bin/pg_dump/.deps
? src/bin/pg_dump/pg_dump
? src/bin/pg_dump/pg_dumpall
? src/bin/pg_dump/pg_restore
? src/bin/pg_encoding/.deps
? src/bin/pg_encoding/pg_encoding
? src/bin/pg_id/.deps
? src/bin/pg_id/pg_id
? src/bin/pg_resetxlog/.deps
? src/bin/pg_resetxlog/pg_resetxlog
? src/bin/psql/.deps
? src/bin/psql/psql
? src/bin/scripts/createlang
? src/include/pg_config.h
? src/include/stamp-h
? src/interfaces/ecpg/lib/.deps
? src/interfaces/ecpg/lib/libecpg.so.3
? src/interfaces/ecpg/preproc/.deps
? src/interfaces/ecpg/preproc/ecpg
? src/interfaces/libpgeasy/.deps
? src/interfaces/libpgeasy/libpgeasy.so.2
? src/interfaces/libpq/.deps
? src/interfaces/libpq/libpq.so.2
? src/pl/plpgsql/src/.deps
? src/pl/plpgsql/src/libplpgsql.so.1
? src/test/regress/.deps
? src/test/regress/log
? src/test/regress/pg_regress
? src/test/regress/regression.diffs
? src/test/regress/regression.out
? src/test/regress/results
? src/test/regress/tmp_check
? src/test/regress/expected/constraints.out
? src/test/regress/expected/copy.out
? src/test/regress/expected/create_function_1.out
? src/test/regress/expected/create_function_2.out
? src/test/regress/expected/misc.out
? src/test/regress/sql/constraints.sql
? src/test/regress/sql/copy.sql
? src/test/regress/sql/create_function_1.sql
? src/test/regress/sql/create_function_2.sql
? src/test/regress/sql/misc.sql
Index: doc/src/sgml/ref/psql-ref.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.80
diff -c -r1.80 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml	2002/11/08 19:12:21	1.80
--- doc/src/sgml/ref/psql-ref.sgml	2002/12/09 04:17:35
***************
*** 852,857 ****
--- 852,880 ----
  
  
        <varlistentry>
+         <term><literal>\dc</literal> [ <replaceable class="parameter">pattern</replaceable> ]</term>
+         <listitem>
+         <para>
+         Lists all available conversions (between encodings). If <replaceable
+         class="parameter">pattern</replaceable>
+         is specified, only matching conversions are shown.
+         </para>
+         </listitem>
+       </varlistentry>
+ 
+ 
+       <varlistentry>
+         <term><literal>\dC</literal></term>
+         <listitem>
+         <para>
+         Lists all available type casts.  Casts can be explicit, explicit and assignment
+ 	or implicit, and are used to change a variable from one type to another.
+         </para>
+         </listitem>
+       </varlistentry>
+ 
+ 
+       <varlistentry>
          <term><literal>\df [ <replaceable class="parameter">pattern</replaceable> ]</literal></term>
  
          <listitem>
Index: src/backend/catalog/namespace.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/backend/catalog/namespace.c,v
retrieving revision 1.41
diff -c -r1.41 namespace.c
*** src/backend/catalog/namespace.c	2002/12/04 05:18:31	1.41
--- src/backend/catalog/namespace.c	2002/12/09 04:17:36
***************
*** 143,150 ****
  Datum		pg_function_is_visible(PG_FUNCTION_ARGS);
  Datum		pg_operator_is_visible(PG_FUNCTION_ARGS);
  Datum		pg_opclass_is_visible(PG_FUNCTION_ARGS);
  
- 
  /*
   * RangeVarGetRelid
   *		Given a RangeVar describing an existing relation,
--- 143,150 ----
  Datum		pg_function_is_visible(PG_FUNCTION_ARGS);
  Datum		pg_operator_is_visible(PG_FUNCTION_ARGS);
  Datum		pg_opclass_is_visible(PG_FUNCTION_ARGS);
+ Datum		pg_conversion_is_visible(PG_FUNCTION_ARGS);
  
  /*
   * RangeVarGetRelid
   *		Given a RangeVar describing an existing relation,
***************
*** 1036,1041 ****
--- 1036,1122 ----
  }
  
  /*
+  * ConversionGetConid
+  *		Try to resolve an unqualified conversion name.
+  *		Returns OID if conversion found in search path, else InvalidOid.
+  *
+  * This is essentially the same as RelnameGetRelid.
+  */
+ Oid
+ ConversionGetConid(const char *conname)
+ {
+ 	Oid		conid;
+ 	List	   *lptr;
+ 
+ 	recomputeNamespacePath();
+ 
+ 	foreach(lptr, namespaceSearchPath)
+ 	{
+ 		Oid			namespaceId = (Oid) lfirsti(lptr);
+ 
+ 		conid = GetSysCacheOid(CONNAMENSP,
+ 							   PointerGetDatum(conname),
+ 							   ObjectIdGetDatum(namespaceId),
+ 							   0, 0);
+ 		if (OidIsValid(conid))
+ 			return conid;
+ 	}
+ 
+ 	/* Not found in path */
+ 	return InvalidOid;
+ }
+ 
+ /*
+  * ConversionIsVisible
+  *		Determine whether a conversion (identified by OID) is visible in the
+  *		current search path.  Visible means "would be found by searching
+  *		for the unqualified conversion name".
+  */
+ bool
+ ConversionIsVisible(Oid conid)
+ {
+ 	HeapTuple	contup;
+ 	Form_pg_conversion conform;
+ 	Oid			connamespace;
+ 	bool		visible;
+ 
+ 	contup = SearchSysCache(CONOID,
+ 							ObjectIdGetDatum(conid),
+ 							0, 0, 0);
+ 	if (!HeapTupleIsValid(contup))
+ 		elog(ERROR, "Cache lookup failed for converions %u", conid);
+ 	conform = (Form_pg_conversion) GETSTRUCT(contup);
+ 
+ 	recomputeNamespacePath();
+ 
+ 	/*
+ 	 * Quick check: if it ain't in the path at all, it ain't visible.
+ 	 * Items in the system namespace are surely in the path and so we
+ 	 * needn't even do intMember() for them.
+ 	 */
+ 	connamespace = conform->connamespace;
+ 	if (connamespace != PG_CATALOG_NAMESPACE &&
+ 		!intMember(connamespace, namespaceSearchPath))
+ 		visible = false;
+ 	else
+ 	{
+ 		/*
+ 		 * If it is in the path, it might still not be visible; it could
+ 		 * be hidden by another conversion of the same name earlier in the
+ 		 * path. So we must do a slow check to see if this conversion would
+ 		 * be found by ConvnameGetConid.
+ 		 */
+ 		char	   *conname = NameStr(conform->conname);
+ 		
+ 		visible = (ConversionGetConid(conname) == conid);
+ 	}
+ 
+ 	ReleaseSysCache(contup);
+ 
+ 	return visible;
+ }
+ 
+ /*
   * DeconstructQualifiedName
   *		Given a possibly-qualified name expressed as a list of String nodes,
   *		extract the schema name and object name.
***************
*** 1853,1856 ****
--- 1934,1945 ----
  	Oid			oid = PG_GETARG_OID(0);
  
  	PG_RETURN_BOOL(OpclassIsVisible(oid));
+ }
+ 
+ Datum
+ pg_conversion_is_visible(PG_FUNCTION_ARGS)
+ {
+ 	Oid			oid = PG_GETARG_OID(0);
+ 
+ 	PG_RETURN_BOOL(ConversionIsVisible(oid));
  }
Index: src/bin/psql/command.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v
retrieving revision 1.85
diff -c -r1.85 command.c
*** src/bin/psql/command.c	2002/11/08 19:12:21	1.85
--- src/bin/psql/command.c	2002/12/09 04:17:38
***************
*** 381,387 ****
  			case 'D':
  				success = listDomains(pattern);
  				break;
! 
  			default:
  				status = CMD_UNKNOWN;
  		}
--- 381,393 ----
  			case 'D':
  				success = listDomains(pattern);
  				break;
! 			case 'c':
! 				success = listConversions(pattern);
! 				break;
! 			case 'C':
! 				success = listCasts(pattern);
! 				break;
! 				
  			default:
  				status = CMD_UNKNOWN;
  		}
Index: src/bin/psql/describe.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/describe.c,v
retrieving revision 1.71
diff -c -r1.71 describe.c
*** src/bin/psql/describe.c	2002/10/19 20:50:44	1.71
--- src/bin/psql/describe.c	2002/12/09 04:17:39
***************
*** 1390,1395 ****
--- 1390,1495 ----
  }
  
  /*
+  * \dc
+  *
+  * Describes conversions.
+  */
+ bool
+ listConversions(const char *pattern)
+ {
+ 	PQExpBufferData buf;
+ 	PGresult   *res;
+ 	printQueryOpt myopt = pset.popt;
+ 
+ 	initPQExpBuffer(&buf);
+ 
+ 	printfPQExpBuffer(&buf,
+ 					  "SELECT n.nspname AS \"%s\",\n"
+ 					  "       c.conname AS \"%s\",\n"
+ 					  "       pg_catalog.pg_encoding_to_char(c.conforencoding) AS \"%s\",\n"
+ 					  "       pg_catalog.pg_encoding_to_char(c.contoencoding) AS \"%s\",\n"
+ 					  "       CASE WHEN c.condefault THEN '%s'\n"
+ 					  "       ELSE NULL END AS \"%s\"\n"
+ 					  "FROM pg_catalog.pg_conversion c, pg_catalog.pg_namespace n\n"
+ 					  "WHERE n.oid = c.connamespace\n",
+ 					  _("Schema"),
+ 					  _("Name"),
+ 					  _("Source"),
+ 					  _("Dest"),
+ 					  _("default"),
+ 					  _("Modifier"));
+ 
+ 	processNamePattern(&buf, pattern, true, false,
+ 					   "n.nspname", "c.conname", NULL,
+ 					   "pg_catalog.pg_conversion_is_visible(c.oid)");
+ 
+ 	appendPQExpBuffer(&buf, "ORDER BY 1, 2;");
+ 
+ 	res = PSQLexec(buf.data, false);
+ 	termPQExpBuffer(&buf);
+ 	if (!res)
+ 		return false;
+ 
+ 	myopt.nullPrint = NULL;
+ 	myopt.title = _("List of conversions");
+ 
+ 	printQuery(res, &myopt, pset.queryFout);
+ 
+ 	PQclear(res);
+ 	return true;
+ }
+ 
+ /*
+  * \dC
+  *
+  * Describes casts.
+  */
+ bool
+ listCasts(const char *pattern)
+ {
+ 	PQExpBufferData buf;
+ 	PGresult   *res;
+ 	printQueryOpt myopt = pset.popt;
+ 
+ 	initPQExpBuffer(&buf);
+ /* NEED LEFT JOIN FOR BINARY CASTS */
+ 	printfPQExpBuffer(&buf,
+ 					  "SELECT t1.typname AS \"%s\",\n"
+ 					  "       t2.typname AS \"%s\",\n"
+ 					  "       CASE WHEN p.proname IS NULL THEN '%s'\n"
+ 					  "            ELSE p.proname\n"
+ 					  "       END as \"%s\",\n"
+ 					  "       CASE WHEN c.castcontext = 'e' THEN '%s'\n"
+ 					  "            WHEN c.castcontext = 'a' THEN '%s'\n"
+ 					  "            ELSE '%s'\n"
+ 					  "       END as \"%s\"\n"
+ 					  "FROM pg_catalog.pg_cast c LEFT JOIN pg_catalog.pg_proc p\n"
+ 					  "       ON c.castfunc=p.oid, pg_catalog.pg_type t1, pg_catalog.pg_type t2\n"
+ 					  "WHERE c.castsource=t1.oid AND c.casttarget=t2.oid ORDER BY 1, 2",
+ 					  _("Source"),
+ 					  _("Target"),
+ 					  _("BINARY"),
+ 					  _("Function"),
+ 					  _("explicit"),
+ 					  _("assignment explicit"),
+ 					  _("implicit"),
+ 					  _("Context"));
+ 
+ 	res = PSQLexec(buf.data, false);
+ 	termPQExpBuffer(&buf);
+ 	if (!res)
+ 		return false;
+ 
+ 	myopt.nullPrint = NULL;
+ 	myopt.title = _("List of casts");
+ 
+ 	printQuery(res, &myopt, pset.queryFout);
+ 
+ 	PQclear(res);
+ 	return true;
+ }
+ 
+ /*
   * processNamePattern
   *
   * Scan a wildcard-pattern option and generate appropriate WHERE clauses
Index: src/bin/psql/describe.h
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/describe.h,v
retrieving revision 1.18
diff -c -r1.18 describe.h
*** src/bin/psql/describe.h	2002/08/27 18:28:29	1.18
--- src/bin/psql/describe.h	2002/12/09 04:17:39
***************
*** 43,46 ****
--- 43,53 ----
  /* \dD */
  bool		listDomains(const char *pattern);
  
+ /* \dc */
+ bool		listConversions(const char *pattern);
+ 
+ /* \dC */
+ bool		listCasts(const char *pattern);
+ 
+ 
  #endif   /* DESCRIBE_H */
Index: src/bin/psql/help.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/help.c,v
retrieving revision 1.61
diff -c -r1.61 help.c
*** src/bin/psql/help.c	2002/11/08 19:12:21	1.61
--- src/bin/psql/help.c	2002/12/09 04:17:39
***************
*** 183,188 ****
--- 183,190 ----
  	fprintf(output, _(" \\d{t|i|s|v|S} [PATTERN] (add \"+\" for more detail)\n"
  					  "                list tables/indexes/sequences/views/system tables\n"));
  	fprintf(output, _(" \\da [PATTERN]  list aggregate functions\n"));
+ 	fprintf(output, _(" \\dc [PATTERN]  list conversions\n"));
+ 	fprintf(output, _(" \\dC            list casts\n"));
  	fprintf(output, _(" \\dd [PATTERN]  show comment for object\n"));
  	fprintf(output, _(" \\dD [PATTERN]  list domains\n"));
  	fprintf(output, _(" \\df [PATTERN]  list functions (add \"+\" for more detail)\n"));
Index: src/include/catalog/namespace.h
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/include/catalog/namespace.h,v
retrieving revision 1.22
diff -c -r1.22 namespace.h
*** src/include/catalog/namespace.h	2002/11/02 18:41:22	1.22
--- src/include/catalog/namespace.h	2002/12/09 04:17:39
***************
*** 65,70 ****
--- 65,72 ----
  extern OpclassCandidateList OpclassGetCandidates(Oid amid);
  extern Oid	OpclassnameGetOpcid(Oid amid, const char *opcname);
  extern bool OpclassIsVisible(Oid opcid);
+ extern bool ConversionIsVisible(Oid opcid);
+ extern Oid	ConversionGetConid(const char *conname);
  
  extern void DeconstructQualifiedName(List *names,
  						 char **nspname_p,
Index: src/include/catalog/pg_proc.h
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/include/catalog/pg_proc.h,v
retrieving revision 1.279
diff -c -r1.279 pg_proc.h
*** src/include/catalog/pg_proc.h	2002/12/06 05:20:26	1.279
--- src/include/catalog/pg_proc.h	2002/12/09 04:17:48
***************
*** 2930,2935 ****
--- 2930,2937 ----
  DESCR("is operator visible in search path?");
  DATA(insert OID = 2083 (  pg_opclass_is_visible		PGNSP PGUID 12 f f t f s 1 16 "26"	pg_opclass_is_visible - _null_ ));
  DESCR("is opclass visible in search path?");
+ DATA(insert OID = 2093 (  pg_conversion_is_visible		PGNSP PGUID 12 f f t f s 1 16 "26"	pg_conversion_is_visible - _null_ ));
+ DESCR("is conversion visible in search path?");
  
  
  /* Aggregates (moved here from pg_aggregate for 7.3) */
#2Peter Eisentraut
peter_e@gmx.net
In reply to: Christopher Kings-Lynne (#1)
Re: show casts and conversions in psql (2nd try)

Christopher Kings-Lynne writes:

\dc - list conversions [PATTERN]
\dC - list casts

What are we going to use for collations?

--
Peter Eisentraut peter_e@gmx.net

#3Christopher Kings-Lynne
chriskl@familyhealth.com.au
In reply to: Peter Eisentraut (#2)
Re: show casts and conversions in psql (2nd try)

Christopher Kings-Lynne writes:

\dc - list conversions [PATTERN]
\dC - list casts

What are we going to use for collations?

\dn Is the only letter left in collations that hasn't been used!

Chris

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Christopher Kings-Lynne (#3)
psql's \d commands --- end of the line for 1-character identifiers?

[ moved to hackers from pgsql-patches ]

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

Peter wrote:

Christopher Kings-Lynne writes:

\dc - list conversions [PATTERN]
\dC - list casts

What are we going to use for collations?

\dn Is the only letter left in collations that hasn't been used!

... and that was already proposed for "show schemas" (namespaces).

I'm inclined to think it's time to bite the bullet and go over to
words rather than single characters to identify the \d target
(viz, "\dschema", "\dcast", etc, presumably with unique abbreviations
being allowed, as well as special cases for the historical single
characters).

The issue here is what do we do with the existing "\d[istvS]" behavior
(for instance, "\dsit" means "list sequences, indexes, and tables").
Is that useful enough to try to preserve, or do we just bit-bucket it?
If we do try to preserve it, how should it work?

regards, tom lane

#5Christopher Kings-Lynne
chriskl@familyhealth.com.au
In reply to: Peter Eisentraut (#2)
Re: psql's \d commands --- end of the line for 1-character identifiers?

... and that was already proposed for "show schemas" (namespaces).

I'm inclined to think it's time to bite the bullet and go over to
words rather than single characters to identify the \d target
(viz, "\dschema", "\dcast", etc, presumably with unique abbreviations
being allowed, as well as special cases for the historical single
characters).

Hmmm...I'm not certain that the \d commands really NEED to have a logical
link to the actual thing you're listing. If you just made \dh for schemas,
people would look it up and then remember it from then on. It's probably
not a huge deal.

We could do DESCRIBE commands as well. Also, what happened to the
INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that?
What happened to it?

The issue here is what do we do with the existing "\d[istvS]" behavior
(for instance, "\dsit" means "list sequences, indexes, and tables").
Is that useful enough to try to preserve, or do we just bit-bucket it?
If we do try to preserve it, how should it work?

I'd much rather it were preserved, and I'm sure most people would as well.

Chris

#6Hannu Krosing
hannu@tm.ee
In reply to: Tom Lane (#4)
Re: psql's \d commands --- end of the line for

Tom Lane kirjutas T, 10.12.2002 kell 02:05:

[ moved to hackers from pgsql-patches ]

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

Peter wrote:

Christopher Kings-Lynne writes:

\dc - list conversions [PATTERN]
\dC - list casts

What are we going to use for collations?

\dn Is the only letter left in collations that hasn't been used!

... and that was already proposed for "show schemas" (namespaces).

I'm inclined to think it's time to bite the bullet and go over to
words rather than single characters to identify the \d target
(viz, "\dschema", "\dcast", etc, presumably with unique abbreviations
being allowed, as well as special cases for the historical single
characters).

The issue here is what do we do with the existing "\d[istvS]" behavior
(for instance, "\dsit" means "list sequences, indexes, and tables").
Is that useful enough to try to preserve, or do we just bit-bucket it?
If we do try to preserve it, how should it work?

Why not use \D for "long" ids ?

Somewhat similar to -? and --help for command line.

--
Hannu Krosing <hannu@tm.ee>

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Hannu Krosing (#6)
Re: psql's \d commands --- end of the line for

Hannu Krosing <hannu@tm.ee> writes:

Why not use \D for "long" ids ?

Seems like a fine idea to me. (I had actually started to think of
"\s<something>" for "show", but was just observing that that would
create conflicts against existing commands, when your message arrived.
"\D<something>" works though.)

Any objections out there?

regards, tom lane

#8Philip Warner
pjw@rhyme.com.au
In reply to: Tom Lane (#7)
Re: psql's \d commands --- end of the line for

At 05:13 PM 9/12/2002 -0500, Tom Lane wrote:

Seems like a fine idea to me.

Ditto.

"\D<something>" works though.)

Any objections out there?

My only complaint here is being forced to use the 'shift' key on commands
that will be common. I would prefer any other lower case char: \b, \j, \k ,
\m, \n, \u, \v, and \y are available. I'd vote for \v (view), or \k
(command). The go with:

\v schema
or
\k show schema

(I'd vote for \v).

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

#9Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Christopher Kings-Lynne (#5)
Re: psql's \d commands --- end of the line for 1-character

Christopher Kings-Lynne wrote:

We could do DESCRIBE commands as well. Also, what happened to the
INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that?
What happened to it?

The issue here is what do we do with the existing "\d[istvS]" behavior
(for instance, "\dsit" means "list sequences, indexes, and tables").
Is that useful enough to try to preserve, or do we just bit-bucket it?
If we do try to preserve it, how should it work?

I'd much rather it were preserved, and I'm sure most people would as well.

I was going to say the opposite, that it isn't needed. Oh well.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#10Philip Warner
pjw@rhyme.com.au
In reply to: Christopher Kings-Lynne (#5)
Re: psql's \d commands --- end of the line for

At 01:22 PM 9/12/2002 -0800, Christopher Kings-Lynne wrote:

Hmmm...I'm not certain that the \d commands really NEED to have a logical
link to the actual thing you're listing.

This is the perspective a person with good memory, unlike me. In find it
useful to be able to derive commands from common-sense rules, even if it
means a little more typing.

We could do DESCRIBE commands as well. Also, what happened to the

This would be fine, so long as the standard does not get in the way of
displaying postgres-specific information (eg. function attrs).

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

#11Alvaro Herrera
alvherre@dcc.uchile.cl
In reply to: Philip Warner (#10)
Re: psql's \d commands --- end of the line for

On Tue, Dec 10, 2002 at 12:55:51PM +1100, Philip Warner wrote:

At 01:22 PM 9/12/2002 -0800, Christopher Kings-Lynne wrote:

Hmmm...I'm not certain that the \d commands really NEED to have a logical
link to the actual thing you're listing.

This is the perspective a person with good memory, unlike me. In find it
useful to be able to derive commands from common-sense rules, even if it
means a little more typing.

Would it work to make \d tab-completable in a way that showed both the
commands that are available and the objects they describe? e.g.

\d<tab> would show something like
\dt [tables] \ds [sequences] \dv [views] ...

(the way it's shown now shows what completions are available, but not
what they mean. Also, both \d and \D should be shown in any case)

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Los romanticos son seres que mueren de deseos de vida"

#12Philip Warner
pjw@rhyme.com.au
In reply to: Alvaro Herrera (#11)
Re: psql's \d commands --- end of the line for

At 01:55 AM 10/12/2002 -0300, Alvaro Herrera wrote:

\d<tab> would show something like
\dt [tables] \ds [sequences] \dv [views] ...

(the way it's shown now shows what completions are available, but not
what they mean. Also, both \d and \D should be shown in any case)

This would be OK, but I'd be very happy with DESCRIBE, especially if
tab-completion meant I could type 'DESC<tab>TAB<tab><name>' instead of
'DESCRIBE TABLE <name>'.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

#13Matthew T. O'Connor
matthew@zeut.net
In reply to: Hannu Krosing (#6)
Re: psql's \d commands --- end of the line for

"\D<something>" works though.)

Any objections out there?

My only complaint here is being forced to use the 'shift' key on commands
that will be common.

\dd perhaps?

#14Tom Lane
tgl@sss.pgh.pa.us
In reply to: Philip Warner (#12)
Re: psql's \d commands --- end of the line for

Philip Warner <pjw@rhyme.com.au> writes:

This would be OK, but I'd be very happy with DESCRIBE, especially if
tab-completion meant I could type 'DESC<tab>TAB<tab><name>' instead of
'DESCRIBE TABLE <name>'.

That's quicker than <backslash><shift><D><unshift><t><space><name> ?

I don't want to sound like I've got some kind of religious objection
to DESCRIBE, but it was just a couple of hours ago that someone was
objecting to "\D" because it'd require touching the shift key. Let's
get a bit realistic on the ease-of-typing arguments here.

regards, tom lane

#15Hannu Krosing
hannu@tm.ee
In reply to: Philip Warner (#8)
Re: psql's \d commands --- end of the line for

On Mon, 2002-12-09 at 23:12, Philip Warner wrote:

At 05:13 PM 9/12/2002 -0500, Tom Lane wrote:

Seems like a fine idea to me.

Ditto.

"\D<something>" works though.)

Any objections out there?

My only complaint here is being forced to use the 'shift' key on commands
that will be common.

On most european keyboards you alreday have to use "AltGr" to get to \
so using an extra shift is not too bad ;)

--
Hannu Krosing <hannu@tm.ee>

#16Christopher Kings-Lynne
chriskl@familyhealth.com.au
In reply to: Philip Warner (#12)
Re: psql's \d commands --- end of the line for

At 01:25 AM 10/12/2002 -0500, Tom Lane wrote:

Let's
get a bit realistic on the ease-of-typing arguments here.

It's a fair cop, but don't forget the memory argument as well - I did say

I

was happy with \d<tab> providing prompts, and DESCRIBE is a little more
portable & memorable than \d[heiroglyphic].

I think the problem with DESCRIBE is that it's supposed to just return a
recordset. I don't see it showing fk's, indexes, rules, etc. as well...

Chris

#17Tom Lane
tgl@sss.pgh.pa.us
In reply to: Christopher Kings-Lynne (#5)
Re: psql's \d commands --- end of the line for 1-character identifiers?

Peter Eisentraut <peter_e@gmx.net> writes:

Christopher Kings-Lynne writes:

We could do DESCRIBE commands as well. Also, what happened to the
INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that?
What happened to it?

Ooops. Yeah, let's get this in. Where should I put it?

How do you mean "where"? The spec says it's gotta be called
information_schema, no? What's left to decide?

regards, tom lane

#18Peter Eisentraut
peter_e@gmx.net
In reply to: Alvaro Herrera (#11)
Re: psql's \d commands --- end of the line for

Alvaro Herrera writes:

Would it work to make \d tab-completable in a way that showed both the
commands that are available and the objects they describe? e.g.

\d<tab> would show something like
\dt [tables] \ds [sequences] \dv [views] ...

That won't work. The actual completion and the view of the alternatives
if the completion is ambiguous is driven by the same data.

--
Peter Eisentraut peter_e@gmx.net

#19Peter Eisentraut
peter_e@gmx.net
In reply to: Christopher Kings-Lynne (#5)
Re: psql's \d commands --- end of the line for 1-character identifiers?

Christopher Kings-Lynne writes:

We could do DESCRIBE commands as well. Also, what happened to the
INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that?
What happened to it?

Ooops. Yeah, let's get this in. Where should I put it?

--
Peter Eisentraut peter_e@gmx.net

#20Christopher Kings-Lynne
chriskl@familyhealth.com.au
In reply to: Peter Eisentraut (#19)
INFORMATION_SCHEMA

We could do DESCRIBE commands as well. Also, what happened to the
INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that?
What happened to it?

Ooops. Yeah, let's get this in. Where should I put it?

I wouldn't mind having a look at the patch. Where do you implement this
kind of thing? Where in the code do you create system views and schemas?
Just add to the initdb script or something?

Adding this should allow us to move around 20 items from the sql99
unsupported list to the supported, which would be sweet.

Chris

#21Christopher Kings-Lynne
chriskl@familyhealth.com.au
In reply to: Peter Eisentraut (#19)
INFORMATION_SCHEMA

We could do DESCRIBE commands as well. Also, what happened to the
INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that?
What happened to it?

Ooops. Yeah, let's get this in. Where should I put it?

I wouldn't mind having a look at the patch. Where do you implement this
kind of thing? Where in the code do you create system views and schemas?
Just add to the initdb script or something?

Adding this should allow us to move around 20 items from the sql99
unsupported list to the supported, which would be sweet.

Chris

#22Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Christopher Kings-Lynne (#1)
Re: show casts and conversions in psql (2nd try)

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:

(Doh! Forgot to attach first time.)

This partially nails this TODO item:

* Add schema, cast, and conversion backslash commands to psql

I had to create a new publically available function,
pg_conversion_is_visible, as it seemed to be missing from the catalogs.
This required me to do no small amount of hacking around in namespace.c

I have updated the \? help and sgml docs.

\dc - list conversions [PATTERN]
\dC - list casts

I didn't support patterns with casts as there's nothing obvious to match
against.

I've tested it a fair bit and I can't see any problems. Feel free to do a
once over on my backend changes tho.

Chris

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#23Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#17)
Re: psql's \d commands --- end of the line for 1-character identifiers?

Tom Lane writes:

How do you mean "where"? The spec says it's gotta be called
information_schema, no? What's left to decide?

I was more wondering where in the source tree to put and how to install
it. I would suggest the following: I have a file information_schema.sql
which contains the commands to create the information schema in a
user-space manner. I'd put it into backend/catalog, from there it gets
installed in the same place the .bki files go, and initdb installs it into
template1 near the end.

Maybe someone wants to make a case for putting the information schema
definitions into a bunch of separate .sql files, one for each item defined
in the standard?

We also have to think whether we want to magically represent the
information_schema in the search path as the spec prescribes. I would
suggest a "no" for that. The names of the objects in the information
schema are way to obvious to put in the default namespace (pun intended
for amusement).

--
Peter Eisentraut peter_e@gmx.net

#24Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#23)
Re: psql's \d commands --- end of the line for 1-character identifiers?

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

How do you mean "where"?

I was more wondering where in the source tree to put and how to install
it. I would suggest the following: I have a file information_schema.sql
which contains the commands to create the information schema in a
user-space manner. I'd put it into backend/catalog, from there it gets
installed in the same place the .bki files go, and initdb installs it into
template1 near the end.

Ah. That works for me.

Maybe someone wants to make a case for putting the information schema
definitions into a bunch of separate .sql files, one for each item defined
in the standard?

One file per item is way overkill ... especially when there's no obvious
reason that people would want some but not all of these items.

We also have to think whether we want to magically represent the
information_schema in the search path as the spec prescribes.

We already have the necessary mechanism to let this be set on a
per-installation (or even per-database or per-user) basis. I agree with
your thought that we need not make it the factory default.

regards, tom lane

#25Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Christopher Kings-Lynne (#1)
Re: show casts and conversions in psql (2nd try)

This is the patch description.

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:

(Doh! Forgot to attach first time.)

This partially nails this TODO item:

* Add schema, cast, and conversion backslash commands to psql

I had to create a new publically available function,
pg_conversion_is_visible, as it seemed to be missing from the catalogs.
This required me to do no small amount of hacking around in namespace.c

I have updated the \? help and sgml docs.

\dc - list conversions [PATTERN]
\dC - list casts

I didn't support patterns with casts as there's nothing obvious to match
against.

I've tested it a fair bit and I can't see any problems. Feel free to do a
once over on my backend changes tho.

Chris

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073