show casts and conversions in psql (2nd try)
(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) */
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
Christopher Kings-Lynne writes:
\dc - list conversions [PATTERN]
\dC - list castsWhat are we going to use for collations?
\dn Is the only letter left in collations that hasn't been used!
Chris
[ 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 castsWhat 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
... 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
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 castsWhat 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>
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
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 |/
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
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 |/
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"
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 |/
"\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?
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
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>
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
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
Import Notes
Reply to msg id not found: Pine.LNX.4.44.0212102010130.25355-100000@localhost.localdomainReference msg id not found: Pine.LNX.4.44.0212102010130.25355-100000@localhost.localdomain | Resolved by subject fallback
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
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
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
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
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.cI have updated the \? help and sgml docs.
\dc - list conversions [PATTERN]
\dC - list castsI 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?
--
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
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
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
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.cI have updated the \? help and sgml docs.
\dc - list conversions [PATTERN]
\dC - list castsI 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?
--
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