opensourcemirror
/
postgresql
mirror of git://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Releases Wiki Activity
postgresql/src/bin/psql/help.c

686 lines
29 KiB
C
Raw Normal View History

another set of cleanups
2000-01-19 00:30:24 +01:00
/*
* psql - the PostgreSQL interactive terminal
*
Update copyrights for 2020 Backpatch-through: update all files in master, backpatch legal files through 9.4
2020-01-01 18:21:45 +01:00
* Copyright (c) 2000-2020, PostgreSQL Global Development Group
another set of cleanups
2000-01-19 00:30:24 +01:00
*
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
* src/bin/psql/help.c
another set of cleanups
2000-01-19 00:30:24 +01:00
*/
Restructure the key include files per recent pghackers discussion: there are now separate files "postgres.h" and "postgres_fe.h", which are meant to be the primary include files for backend .c files and frontend .c files respectively. By default, only include files meant for frontend use are installed into the installation include directory. There is a new make target 'make install-all-headers' that adds the whole content of the src/include tree to the installed fileset, for use by people who want to develop server-side code without keeping the complete source tree on hand. Cleaned up a whole lot of crufty and inconsistent header inclusions.
2001-02-10 03:31:31 +01:00
#include "postgres_fe.h"
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
#ifndef WIN32
Consistently use geteuid() not getuid(); there were a few places deviating from our long-established standard.
2005-01-08 23:51:15 +01:00
#include <unistd.h> /* for geteuid() */
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
#else
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
#include <win32.h>
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
#endif
Fix psql \h output for case of no parameters (ie, list all the known commands) to format properly for the actually needed column width, instead of having a hard-wired assumption about the longest command name length. Also make it respond to the current screen width. In passing, const-ify the constant table.
2008-01-20 22:13:55 +01:00
#ifndef WIN32
#include <sys/ioctl.h> /* for ioctl() */
#endif
#ifdef HAVE_TERMIOS_H
#include <termios.h>
#endif
Make the order of the header file includes consistent in non-backend modules. Similar to commit 7e735035f2, this commit makes the order of header file inclusion consistent for non-backend modules. In passing, fix the case where we were using angle brackets (<>) for the local module includes instead of quotes (""). Author: Vignesh C Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com
2019-10-23 06:08:53 +02:00
#include "common.h"
Move logging.h and logging.c from src/fe_utils/ to src/common/. The original placement of this module in src/fe_utils/ is ill-considered, because several src/common/ modules have dependencies on it, meaning that libpgcommon and libpgfeutils now have mutual dependencies. That makes it pointless to have distinct libraries at all. The intended design is that libpgcommon is lower-level than libpgfeutils, so only dependencies from the latter to the former are acceptable. We already have the precedent that fe_memutils and a couple of other modules in src/common/ are frontend-only, so it's not stretching anything out of whack to treat logging.c as a frontend-only module in src/common/. To the extent that such modules help provide a common frontend/backend environment for the rest of common/ to use, it's a reasonable design. (logging.c does not yet provide an ereport() emulation, but one can dream.) Hence, move these files over, and revert basically all of the build-system changes made by commit cc8d41511. There are no places that need to grow new dependencies on libpgcommon, further reinforcing the idea that this is the right solution. Discussion: https://postgr.es/m/a912ffff-f6e4-778a-c86a-cf5c47a12933@2ndquadrant.com
2019-05-14 20:19:49 +02:00
#include "common/logging.h"
Move username lookup functions from /port to /common Per suggestion from Peter E and Alvaro
2014-01-11 00:03:28 +01:00
#include "common/username.h"
Fix some missing inclusions identified with new pgcheckdefines tool.
2006-07-15 05:35:21 +02:00
#include "help.h"
#include "input.h"
#include "settings.h"
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
#include "sql_help.h"
Moved psql \eset and \eshow to \encoding Improved psql's Ctrl-C handling Fixed configure test for sigsetjmp that now even recognizes it if it's a macro
2000-02-20 15:28:28 +01:00
/*
* PLEASE:
* If you change something in this file, also make the same changes
* in the DocBook documentation, file ref/psql-ref.sgml. If you don't
* know how to do it, please find someone who can help you.
*/
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
/*
* usage
*
Fixed a few "fixes" and bugs. Adjusted messages and options to GNU suggestions.
2000-01-12 20:36:36 +01:00
* print out command line arguments
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
*/
Native Language Support (NLS) Use --enable-nls to turn it on; see installation instructions for details. See developer's guide how to make use of it in programs and how to add translations. psql sources have been almost fully prepared and an incomplete German translation has been provided. In the backend, only elog() calls are currently translatable, and the provided German translation file is more of a placeholder.
2001-06-02 20:25:18 +02:00
#define ON(var) (var ? _("on") : _("off"))
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
psql cleanup
1999-11-05 00:14:30 +01:00
void
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
usage(unsigned short int pager)
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
{
psql cleanup
1999-11-05 00:14:30 +01:00
const char *env;
const char *user;
Fix incorrect error message reported for non-existent users Previously, lookups of non-existent user names could return "Success"; it will now return "User does not exist" by resetting errno. This also centralizes the user name lookup code in libpgport. Report and analysis by Nicolas Marchildon; patch by me
2013-12-18 18:16:16 +01:00
char *errstr;
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
FILE *output;
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
psql cleanup
1999-11-05 00:14:30 +01:00
/* Find default user, in case we need it. */
Make sure all clients have the same understanding of default user name and database. In particular, make script wrappers understand the PGDATABASE environment variable.
2002-08-10 18:57:32 +02:00
user = getenv("PGUSER");
psql cleanup
1999-11-05 00:14:30 +01:00
if (!user)
{
Fix incorrect error message reported for non-existent users Previously, lookups of non-existent user names could return "Success"; it will now return "User does not exist" by resetting errno. This also centralizes the user name lookup code in libpgport. Report and analysis by Nicolas Marchildon; patch by me
2013-12-18 18:16:16 +01:00
user = get_user_name(&errstr);
if (!user)
psql cleanup
1999-11-05 00:14:30 +01:00
{
Unified logging system for command-line programs This unifies the various ad hoc logging (message printing, error printing) systems used throughout the command-line programs. Features: - Program name is automatically prefixed. - Message string does not end with newline. This removes a common source of inconsistencies and omissions. - Additionally, a final newline is automatically stripped, simplifying use of PQerrorMessage() etc., another common source of mistakes. - I converted error message strings to use %m where possible. - As a result of the above several points, more translatable message strings can be shared between different components and between frontends and backend, without gratuitous punctuation or whitespace differences. - There is support for setting a "log level". This is not meant to be user-facing, but can be used internally to implement debug or verbose modes. - Lazy argument evaluation, so no significant overhead if logging at some level is disabled. - Some color in the messages, similar to gcc and clang. Set PG_COLOR=auto to try it out. Some colors are predefined, but can be customized by setting PG_COLORS. - Common files (common/, fe_utils/, etc.) can handle logging much more simply by just using one API without worrying too much about the context of the calling program, requiring callbacks, or having to pass "progname" around everywhere. - Some programs called setvbuf() to make sure that stderr is unbuffered, even on Windows. But not all programs did that. This is now done centrally. Soft goals: - Reduces vertical space use and visual complexity of error reporting in the source code. - Encourages more deliberate classification of messages. For example, in some cases it wasn't clear without analyzing the surrounding code whether a message was meant as an error or just an info. - Concepts and terms are vaguely aligned with popular logging frameworks such as log4j and Python logging. This is all just about printing stuff out. Nothing affects program flow (e.g., fatal exits). The uses are just too varied to do that. Some existing code had wrappers that do some kind of print-and-exit, and I adapted those. I tried to keep the output mostly the same, but there is a lot of historical baggage to unwind and special cases to consider, and I might not always have succeeded. One significant change is that pg_rewind used to write all error messages to stdout. That is now changed to stderr. Reviewed-by: Donald Dong <xdong@csumb.edu> Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru> Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
pg_log_fatal("%s", errstr);
psql cleanup
1999-11-05 00:14:30 +01:00
exit(EXIT_FAILURE);
}
}
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
Rearrange the handling of error context reports. Remove the code in plpgsql that suppressed the innermost line of CONTEXT for messages emitted by RAISE commands. That was never more than a quick backwards-compatibility hack, and it's pretty silly in cases where the RAISE is nested in several levels of function. What's more, it violated our design theory that verbosity of error reports should be controlled on the client side not the server side. To alleviate the resulting noise increase, introduce a feature in libpq and psql whereby the CONTEXT field of messages can be suppressed, either always or only for non-error messages. Printing CONTEXT for errors only is now their default behavior. The actual code changes here are pretty small, but the effects on the regression test outputs are widespread. I had to edit some of the alternative expected outputs by hand; hopefully the buildfarm will soon find anything I fat-fingered. In passing, fix up (again) the output line counts in psql's various help displays. Add some commentary about how to verify them. Pavel Stehule, reviewed by Petr Jelínek, Jeevan Chalke, and others
2015-09-05 17:58:20 +02:00
/*
* Keep this line count in sync with the number of lines printed below!
* Use "psql --help=options | wc" to count correctly.
*/
Add CSV table output mode in psql. "\pset format csv", or --csv, selects comma-separated values table format. This is compliant with RFC 4180, except that we aren't too picky about whether the record separator is LF or CRLF; also, the user may choose a field separator other than comma. This output format is directly compatible with the server's COPY CSV format, and will also be useful as input to other programs. It's considerably safer for that purpose than the old recommendation to use "unaligned" format, since the latter couldn't handle data containing the field separator character. Daniel Vérité, reviewed by Fabien Coelho and David Fetter, some tweaking by me Discussion: https://postgr.es/m/a8de371e-006f-4f92-ab72-2bbe3ee78f03@manitou-mail.org
2018-11-26 21:18:55 +01:00
output = PageOutput(62, pager ? &(pset.popt.topt) : NULL);
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _("psql is the PostgreSQL interactive terminal.\n\n"));
fprintf(output, _("Usage:\n"));
fprintf(output, _(" psql [OPTION]... [DBNAME [USERNAME]]\n\n"));
psql cleanup
1999-11-05 00:14:30 +01:00
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _("General options:\n"));
psql cleanup
1999-11-05 00:14:30 +01:00
/* Display default database */
env = getenv("PGDATABASE");
if (!env)
env = user;
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" -c, --command=COMMAND run only single command (SQL or internal) and exit\n"));
fprintf(output, _(" -d, --dbname=DBNAME database name to connect to (default: \"%s\")\n"), env);
fprintf(output, _(" -f, --file=FILENAME execute commands from file, then exit\n"));
fprintf(output, _(" -l, --list list available databases, then exit\n"));
fprintf(output, _(" -v, --set=, --variable=NAME=VALUE\n"
Phase 3 of pgindent updates. Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
" set psql variable NAME to VALUE\n"
" (e.g., -v ON_ERROR_STOP=1)\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" -V, --version output version information, then exit\n"));
fprintf(output, _(" -X, --no-psqlrc do not read startup file (~/.psqlrc)\n"));
fprintf(output, _(" -1 (\"one\"), --single-transaction\n"
pgindent run for 9.5
2015-05-24 03:35:49 +02:00
" execute as a single transaction (if non-interactive)\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" -?, --help[=options] show this help, then exit\n"));
Review program help output for wording and formatting
2015-09-16 06:37:39 +02:00
fprintf(output, _(" --help=commands list backslash commands, then exit\n"));
fprintf(output, _(" --help=variables list special variables, then exit\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _("\nInput and output options:\n"));
fprintf(output, _(" -a, --echo-all echo all input from script\n"));
fprintf(output, _(" -b, --echo-errors echo failed commands\n"));
fprintf(output, _(" -e, --echo-queries echo commands sent to server\n"));
fprintf(output, _(" -E, --echo-hidden display queries that internal commands generate\n"));
fprintf(output, _(" -L, --log-file=FILENAME send session log to file\n"));
fprintf(output, _(" -n, --no-readline disable enhanced command line editing (readline)\n"));
fprintf(output, _(" -o, --output=FILENAME send query results to file (or |pipe)\n"));
fprintf(output, _(" -q, --quiet run quietly (no messages, only query output)\n"));
fprintf(output, _(" -s, --single-step single-step mode (confirm each query)\n"));
fprintf(output, _(" -S, --single-line single-line mode (end of line terminates SQL command)\n"));
fprintf(output, _("\nOutput format options:\n"));
fprintf(output, _(" -A, --no-align unaligned table output mode\n"));
Add CSV table output mode in psql. "\pset format csv", or --csv, selects comma-separated values table format. This is compliant with RFC 4180, except that we aren't too picky about whether the record separator is LF or CRLF; also, the user may choose a field separator other than comma. This output format is directly compatible with the server's COPY CSV format, and will also be useful as input to other programs. It's considerably safer for that purpose than the old recommendation to use "unaligned" format, since the latter couldn't handle data containing the field separator character. Daniel Vérité, reviewed by Fabien Coelho and David Fetter, some tweaking by me Discussion: https://postgr.es/m/a8de371e-006f-4f92-ab72-2bbe3ee78f03@manitou-mail.org
2018-11-26 21:18:55 +01:00
fprintf(output, _(" --csv CSV (Comma-Separated Values) table output mode\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" -F, --field-separator=STRING\n"
pgindent run for 9.5
2015-05-24 03:35:49 +02:00
" field separator for unaligned output (default: \"%s\")\n"),
DEFAULT_FIELD_SEP);
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" -H, --html HTML table output mode\n"));
fprintf(output, _(" -P, --pset=VAR[=ARG] set printing option VAR to ARG (see \\pset command)\n"));
fprintf(output, _(" -R, --record-separator=STRING\n"
pgindent run for 9.5
2015-05-24 03:35:49 +02:00
" record separator for unaligned output (default: newline)\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" -t, --tuples-only print rows only\n"));
fprintf(output, _(" -T, --table-attr=TEXT set HTML table tag attributes (e.g., width, border)\n"));
fprintf(output, _(" -x, --expanded turn on expanded table output\n"));
fprintf(output, _(" -z, --field-separator-zero\n"
pgindent run for 9.5
2015-05-24 03:35:49 +02:00
" set field separator for unaligned output to zero byte\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" -0, --record-separator-zero\n"
pgindent run for 9.5
2015-05-24 03:35:49 +02:00
" set record separator for unaligned output to zero byte\n"));
Add the long options to the psql --help display, where they were curiously missing. Since this touches most lines of the help output, also change the mix of puts and printf calls to printf everywhere, for easier code editing and reviewing.
2009-02-27 10:58:09 +01:00
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _("\nConnection options:\n"));
psql cleanup
1999-11-05 00:14:30 +01:00
/* Display default host */
env = getenv("PGHOST");
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" -h, --host=HOSTNAME database server host or socket directory (default: \"%s\")\n"),
pgindent run for 9.5
2015-05-24 03:35:49 +02:00
env ? env : _("local socket"));
psql cleanup
1999-11-05 00:14:30 +01:00
/* Display default port */
env = getenv("PGPORT");
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" -p, --port=PORT database server port (default: \"%s\")\n"),
pgindent run for 9.5
2015-05-24 03:35:49 +02:00
env ? env : DEF_PGPORT_STR);
psql cleanup
1999-11-05 00:14:30 +01:00
/* Display default user */
env = getenv("PGUSER");
if (!env)
env = user;
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" -U, --username=USERNAME database user name (default: \"%s\")\n"), env);
fprintf(output, _(" -w, --no-password never prompt for password\n"));
fprintf(output, _(" -W, --password force password prompt (should happen automatically)\n"));
Add the long options to the psql --help display, where they were curiously missing. Since this touches most lines of the help output, also change the mix of puts and printf calls to printf everywhere, for easier code editing and reviewing.
2009-02-27 10:58:09 +01:00
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _("\nFor more information, type \"\\?\" (for internal commands) or \"\\help\" (for SQL\n"
pgindent run for 9.5
2015-05-24 03:35:49 +02:00
"commands) from within psql, or consult the psql section in the PostgreSQL\n"
"documentation.\n\n"));
Refer to bug report address by symbol rather than hardcoding Use the PACKAGE_BUGREPORT macro that is created by Autoconf for referring to the bug reporting address rather than hardcoding it everywhere. This makes it easier to change the address and it reduces translation work. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://www.postgresql.org/message-id/flat/8d389c5f-7fb5-8e48-9a4a-68cec44786fa%402ndquadrant.com
2020-02-28 08:54:49 +01:00
fprintf(output, _("Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);
Add PostgreSQL home page to --help output Per emerging standard in GNU programs and elsewhere. Autoconf already has support for specifying a home page, so we can just that. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://www.postgresql.org/message-id/flat/8d389c5f-7fb5-8e48-9a4a-68cec44786fa%402ndquadrant.com
2020-02-28 08:54:49 +01:00
fprintf(output, _("%s home page: <%s>\n"), PACKAGE_NAME, PACKAGE_URL);
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
ClosePager(output);
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
}
/*
* slashUsage
*
* print out help for the backslash commands
*/
void
Here is a patch that does just that, while maintaining the "traditional" behavior, so the change should be transparent. Use the command "\pset pager always" to turn it on. Anything else does the normal toggle between "on" and "off" Greg Sabino Mullane
2002-11-08 20:12:21 +01:00
slashUsage(unsigned short int pager)
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
{
Page \h output and centralize psql paging code in PageOutput().
2002-10-23 21:23:57 +02:00
FILE *output;
Don't pass NULL to fprintf, if not currently connected to a database. Backpatch all the way to 8.3. Fixes bug #7811, per report and diagnosis by Meng Qingzhong.
2013-01-15 17:54:03 +01:00
char *currdb;
currdb = PQdb(pset.db);
Fix \? and \pset pager handling. \? wasn't honoring pager before.
2002-07-15 03:56:25 +02:00
Rearrange the handling of error context reports. Remove the code in plpgsql that suppressed the innermost line of CONTEXT for messages emitted by RAISE commands. That was never more than a quick backwards-compatibility hack, and it's pretty silly in cases where the RAISE is nested in several levels of function. What's more, it violated our design theory that verbosity of error reports should be controlled on the client side not the server side. To alleviate the resulting noise increase, introduce a feature in libpq and psql whereby the CONTEXT field of messages can be suppressed, either always or only for non-error messages. Printing CONTEXT for errors only is now their default behavior. The actual code changes here are pretty small, but the effects on the regression test outputs are widespread. I had to edit some of the alternative expected outputs by hand; hopefully the buildfarm will soon find anything I fat-fingered. In passing, fix up (again) the output line counts in psql's various help displays. Add some commentary about how to verify them. Pavel Stehule, reviewed by Petr Jelínek, Jeevan Chalke, and others
2015-09-05 17:58:20 +02:00
/*
* Keep this line count in sync with the number of lines printed below!
* Use "psql --help=commands | wc" to count correctly. It's okay to count
* the USE_READLINE line even in builds without that.
*/
Add \warn command to psql. This is like \echo except that the text is sent to stderr not stdout. In passing, fix a pre-existing bug in \echo and \qecho: per documentation the -n switch should only be recognized when it is the first argument, but actually any argument matching "-n" was treated as a switch. (Should we back-patch that?) David Fetter (bug fix by me), reviewed by Fabien Coelho Discussion: https://postgr.es/m/20190421183115.GA4311@fetter.org
2019-07-05 18:32:36 +02:00
output = PageOutput(128, pager ? &(pset.popt.topt) : NULL);
pgindent run.
2002-09-04 22:31:48 +02:00
Reorder psql \? help into groupings, idea from Harald Armin Massa.
2002-12-11 23:45:13 +01:00
fprintf(output, _("General\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\copyright show PostgreSQL usage and distribution terms\n"));
Put documentation of options and commands in more alphabetical order
2017-06-14 17:09:33 +02:00
fprintf(output, _(" \\crosstabview [COLUMNS] execute query and display results in crosstab\n"));
Add psql \errverbose command to see last server error at full verbosity. Often, upon getting an unexpected error in psql, one's first wish is that the verbosity setting had been higher; for example, to be able to see the schema-name field or the server code location info. Up to now the only way has been to adjust the VERBOSITY variable and repeat the failing query. That's a pain, and it doesn't work if the error isn't reproducible. This commit adds a psql feature that redisplays the most recent server error at full verbosity, without needing to make any variable changes or re-execute the failed command. We just need to hang onto the latest error PGresult in case the user executes \errverbose, and then apply libpq's new PQresultVerboseErrorMessage() function to it. This will consume some trivial amount of psql memory, but otherwise the cost when the feature isn't used should be negligible. Alex Shulgin, reviewed by Daniel Vérité, some improvements by me
2016-04-03 18:29:55 +02:00
fprintf(output, _(" \\errverbose show most recent error message at maximum verbosity\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\g [FILE] or ; execute query (and send results to file or |pipe)\n"));
Add \gdesc psql command. This command acts somewhat like \g, but instead of executing the query buffer, it merely prints a description of the columns that the query result would have. (Of course, this still requires parsing the query; if parse analysis fails, you get an error anyway.) We accomplish this using an unnamed prepared statement, which should be invisible to psql users. Pavel Stehule, reviewed by Fabien Coelho Discussion: https://postgr.es/m/CAFj8pRBhYVvO34FU=EKb=nAF5t3b++krKt1FneCmR0kuF5m-QA@mail.gmail.com
2017-09-06 00:17:47 +02:00
fprintf(output, _(" \\gdesc describe result of query, without executing it\n"));
Add a \gexec command to psql for evaluation of computed queries. \gexec executes the just-entered query, like \g, but instead of printing the results it takes each field as a SQL command to send to the server. Computing a series of queries to be executed is a fairly common thing, but up to now you always had to resort to kluges like writing the queries to a file and then inputting the file. Now it can be done with no intermediate step. The implementation is fairly straightforward except for its interaction with FETCH_COUNT. ExecQueryUsingCursor isn't capable of being called recursively, and even if it were, its need to create a transaction block interferes unpleasantly with the desired behavior of \gexec after a failure of a generated query (i.e., that it can continue). Therefore, disable use of ExecQueryUsingCursor when doing the master \gexec query. We can still apply it to individual generated queries, however, and there might be some value in doing so. While testing this feature's interaction with single-step mode, I (tgl) was led to conclude that SendQuery needs to recognize SIGINT (cancel_pressed) as a negative response to the single-step prompt. Perhaps that's a back-patchable bug fix, but for now I just included it here. Corey Huinker, reviewed by Jim Nasby, Daniel Vérité, and myself
2016-04-04 21:25:16 +02:00
fprintf(output, _(" \\gexec execute query, then execute each value in its result\n"));
Create a psql command \gset to store query results into psql variables. This eases manipulation of query results in psql scripts. Pavel Stehule, reviewed by Piyush Newe, Shigeru Hanada, and Tom Lane
2013-02-02 23:06:38 +01:00
fprintf(output, _(" \\gset [PREFIX] execute query and store results in psql variables\n"));
Put documentation of options and commands in more alphabetical order
2017-06-14 17:09:33 +02:00
fprintf(output, _(" \\gx [FILE] as \\g, but forces expanded output mode\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\q quit psql\n"));
Add \watch [SEC] command to psql. This allows convenient re-execution of commands. Will Leinweber, reviewed by Peter Eisentraut, Daniel Farina, and Tom Lane
2013-04-05 01:56:33 +02:00
fprintf(output, _(" \\watch [SEC] execute query every SEC seconds\n"));
Apply message style guide to frontend programs.
2003-07-23 10:47:41 +02:00
fprintf(output, "\n");
Reorder psql \? help into groupings, idea from Harald Armin Massa.
2002-12-11 23:45:13 +01:00
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _("Help\n"));
psql: Review of new help output strings
2015-12-20 17:50:04 +01:00
fprintf(output, _(" \\? [commands] show help on backslash commands\n"));
fprintf(output, _(" \\? options show help on psql command-line options\n"));
fprintf(output, _(" \\? variables show help on special variables\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" \\h [NAME] help on syntax of SQL commands, * for all commands\n"));
fprintf(output, "\n");
Reorder psql \? help into groupings, idea from Harald Armin Massa.
2002-12-11 23:45:13 +01:00
fprintf(output, _("Query Buffer\n"));
Extend psql's \e and \ef commands so that a line number can be specified, and the editor's cursor will be initially placed on that line. In \e the lines are counted with respect to the query buffer, while in \ef they are counted with line 1 = first line of function body. These choices are useful for positioning the cursor on the line of a previously-reported error. To avoid assumptions about what switch the user's editor takes for this purpose, invent a new psql variable EDITOR_LINENUMBER_SWITCH with (at present) no default value. One incompatibility from previous behavior is that "\e 1234" will now take "1234" as a line number not a file name. There are at least two ways to select a numerically-named file if you really want to. Pavel Stehule, reviewed by Jan Urbanski, with further editing by Robert Haas and Tom Lane
2010-08-12 02:40:59 +02:00
fprintf(output, _(" \\e [FILE] [LINE] edit the query buffer (or file) with external editor\n"));
fprintf(output, _(" \\ef [FUNCNAME [LINE]] edit function definition with external editor\n"));
Add psql \ev and \sv commands for editing and showing view definitions. These are basically just like the \ef and \sf commands for functions. Petr Korobeinikov, reviewed by Jeevan Chalke, some changes by me
2015-07-03 21:48:18 +02:00
fprintf(output, _(" \\ev [VIEWNAME [LINE]] edit view definition with external editor\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\p show the contents of the query buffer\n"));
fprintf(output, _(" \\r reset (clear) the query buffer\n"));
Suppress psql \s help display for platforms like Win32 that don't typically install witn readline, and throw an error if they try to access it.
2004-10-06 20:39:16 +02:00
#ifdef USE_READLINE
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\s [FILE] display history or save it to file\n"));
Suppress psql \s help display for platforms like Win32 that don't typically install witn readline, and throw an error if they try to access it.
2004-10-06 20:39:16 +02:00
#endif
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\w FILE write query buffer to file\n"));
Apply message style guide to frontend programs.
2003-07-23 10:47:41 +02:00
fprintf(output, "\n");
Reorder psql \? help into groupings, idea from Harald Armin Massa.
2002-12-11 23:45:13 +01:00
Increment libpq major number for 7.3.1 and minor for 7.4.
2002-12-13 23:17:57 +01:00
fprintf(output, _("Input/Output\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\copy ... perform SQL COPY with data stream to the client host\n"));
Add \warn command to psql. This is like \echo except that the text is sent to stderr not stdout. In passing, fix a pre-existing bug in \echo and \qecho: per documentation the -n switch should only be recognized when it is the first argument, but actually any argument matching "-n" was treated as a switch. (Should we back-patch that?) David Fetter (bug fix by me), reviewed by Fabien Coelho Discussion: https://postgr.es/m/20190421183115.GA4311@fetter.org
2019-07-05 18:32:36 +02:00
fprintf(output, _(" \\echo [-n] [STRING] write string to standard output (-n for no newline)\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\i FILE execute commands from file\n"));
Add \ir command to psql. \ir is short for "include relative"; when used from a script, the supplied pathname will be interpreted relative to the input file, rather than to the current working directory. Gurjeet Singh, reviewed by Josh Kupershmidt, with substantial further cleanup by me.
2011-07-06 17:45:13 +02:00
fprintf(output, _(" \\ir FILE as \\i, but relative to location of current script\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\o [FILE] send all query results to file or |pipe\n"));
Add \warn command to psql. This is like \echo except that the text is sent to stderr not stdout. In passing, fix a pre-existing bug in \echo and \qecho: per documentation the -n switch should only be recognized when it is the first argument, but actually any argument matching "-n" was treated as a switch. (Should we back-patch that?) David Fetter (bug fix by me), reviewed by Fabien Coelho Discussion: https://postgr.es/m/20190421183115.GA4311@fetter.org
2019-07-05 18:32:36 +02:00
fprintf(output, _(" \\qecho [-n] [STRING] write string to \\o output stream (-n for no newline)\n"));
fprintf(output, _(" \\warn [-n] [STRING] write string to standard error (-n for no newline)\n"));
Apply message style guide to frontend programs.
2003-07-23 10:47:41 +02:00
fprintf(output, "\n");
psql \? rearrangement, suggested by Tom.
2002-12-12 00:03:45 +01:00
Support \if ... \elif ... \else ... \endif in psql scripting. This patch adds nestable conditional blocks to psql. The control structure feature per se is complete, but the boolean expressions understood by \if and \elif are pretty primitive; basically, after variable substitution and backtick expansion, the result has to be "true" or "false" or one of the other standard spellings of a boolean value. But that's enough for many purposes, since you can always do the heavy lifting on the server side; and we can extend it later. Along the way, pay down some of the technical debt that had built up around psql/command.c: * Refactor exec_command() into a function per command, instead of being a 1500-line monstrosity. This makes the file noticeably longer because of repetitive function header/trailer overhead, but it seems much more readable. * Teach psql_get_variable() and psqlscanslash.l to suppress variable substitution and backtick expansion on the basis of the conditional stack state, thereby allowing removal of the OT_NO_EVAL kluge. * Fix the no-doubt-once-expedient hack of sometimes silently substituting mainloop.c's previous_buf for query_buf when calling HandleSlashCmds. (It's a bit remarkable that commands like \r worked at all with that.) Recall of a previous query is now done explicitly in the slash commands where that should happen. Corey Huinker, reviewed by Fabien Coelho, further hacking by me Discussion: https://postgr.es/m/CADkLM=c94OSRTnat=LX0ivNq4pxDNeoomFfYvBKM5N_xfmLtAA@mail.gmail.com
2017-03-30 18:59:11 +02:00
fprintf(output, _("Conditional\n"));
fprintf(output, _(" \\if EXPR begin conditional block\n"));
fprintf(output, _(" \\elif EXPR alternative within current conditional block\n"));
fprintf(output, _(" \\else final alternative within current conditional block\n"));
fprintf(output, _(" \\endif end conditional block\n"));
fprintf(output, "\n");
Reorder psql \? help into groupings, idea from Harald Armin Massa.
2002-12-11 23:45:13 +01:00
fprintf(output, _("Informational\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" (options: S = show system objects, + = additional detail)\n"));
fprintf(output, _(" \\d[S+] list tables, views, and sequences\n"));
fprintf(output, _(" \\d[S+] NAME describe table, view, sequence, or index\n"));
Fix psql help: \da+ is same as \da, but \daS is not. Noted by Stephen Frost.
2010-05-26 21:29:22 +02:00
fprintf(output, _(" \\da[S] [PATTERN] list aggregates\n"));
Fix loose ends for SQL ACCESS METHOD objects COMMENT ON ACCESS METHOD was missing; add it, along psql tab-completion support for it. psql was also missing a way to list existing access methods; the new \dA command does that. Also add tab-completion support for DROP ACCESS METHOD. Author: Michael Paquier Discussion: https://www.postgresql.org/message-id/CAB7nPqTzdZdu8J7EF8SXr_R2U5bSUUYNOT3oAWBZdEoggnwhGA@mail.gmail.com
2016-06-07 23:59:34 +02:00
fprintf(output, _(" \\dA[+] [PATTERN] list access methods\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\db[+] [PATTERN] list tablespaces\n"));
Teach psql to display the comments on conversions and domains. \dc and \dD now accept a "+" option, which will cause the comments to be displayed. Along the way, correct a few oversights in the previous commit in this area, 3b17efdfdd846c9bfad1637686e6f18198ea3df5 - namely, (1) when \dL+ is used, make description still be the last column, for consistency with what we've done elsewhere; and (2) document the difference between \dC and \dC+. Josh Kupershmidt, with a couple of doc changes by me.
2011-08-08 18:26:13 +02:00
fprintf(output, _(" \\dc[S+] [PATTERN] list conversions\n"));
Teach psql to display comments on languages and casts. The output of \dL (list languages) is fairly narrow, so we just always display the comment. \dC (list casts) can get fairly wide, so we only display comments if the new \dC+ option is specified. Josh Kupershmidt
2011-08-04 18:22:26 +02:00
fprintf(output, _(" \\dC[+] [PATTERN] list casts\n"));
Change psql's \dd command to do something more useful. Instead of displaying comments on an arbitrary subset of the object types which support them, make \dd display comments on exactly those object types which don't have their own backlash commands. We now regard the display of comments as properly the job of the relevant backslash command (though many of them do so only in verbose mode) rather than something that \dd should be responsible for. However, a handful of object types have no backlash command, so make \dd give information about those. Josh Kupershmidt
2011-08-11 17:16:29 +02:00
fprintf(output, _(" \\dd[S] [PATTERN] show object descriptions not displayed elsewhere\n"));
Teach psql to display the comments on conversions and domains. \dc and \dD now accept a "+" option, which will cause the comments to be displayed. Along the way, correct a few oversights in the previous commit in this area, 3b17efdfdd846c9bfad1637686e6f18198ea3df5 - namely, (1) when \dL+ is used, make description still be the last column, for consistency with what we've done elsewhere; and (2) document the difference between \dC and \dC+. Josh Kupershmidt, with a couple of doc changes by me.
2011-08-08 18:26:13 +02:00
fprintf(output, _(" \\dD[S+] [PATTERN] list domains\n"));
Put documentation of options and commands in more alphabetical order
2017-06-14 17:09:33 +02:00
fprintf(output, _(" \\ddp [PATTERN] list default privileges\n"));
fprintf(output, _(" \\dE[S+] [PATTERN] list foreign tables\n"));
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
fprintf(output, _(" \\det[+] [PATTERN] list foreign tables\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\des[+] [PATTERN] list foreign servers\n"));
fprintf(output, _(" \\deu[+] [PATTERN] list user mappings\n"));
fprintf(output, _(" \\dew[+] [PATTERN] list foreign-data wrappers\n"));
psql: Add option for procedures to \df
2018-07-14 12:17:49 +02:00
fprintf(output, _(" \\df[anptw][S+] [PATRN] list [only agg/normal/procedures/trigger/window] functions\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\dF[+] [PATTERN] list text search configurations\n"));
fprintf(output, _(" \\dFd[+] [PATTERN] list text search dictionaries\n"));
fprintf(output, _(" \\dFp[+] [PATTERN] list text search parsers\n"));
fprintf(output, _(" \\dFt[+] [PATTERN] list text search templates\n"));
Reserve the "pg_" namespace for roles This will prevent users from creating roles which begin with "pg_" and will check for those roles before allowing an upgrade using pg_upgrade. This will allow for default roles to be provided at initdb time. Reviews by José Luis Tallón and Robert Haas
2016-04-08 22:56:27 +02:00
fprintf(output, _(" \\dg[S+] [PATTERN] list roles\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\di[S+] [PATTERN] list indexes\n"));
fprintf(output, _(" \\dl list large objects, same as \\lo_list\n"));
Add new psql command \dL to list languages. Original patch by Fernando Ike, revived by Josh Kuperschmidt, reviewed by Andreas Karlsson, and in earlier versions by Tom Lane and Peter Eisentraut.
2011-01-20 06:00:30 +01:00
fprintf(output, _(" \\dL[S+] [PATTERN] list procedural languages\n"));
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
fprintf(output, _(" \\dm[S+] [PATTERN] list materialized views\n"));
Document the "S" option for psql's \dn command in the psql help This option was recently introduced, but the documentation in help.c was not updated.
2011-01-25 00:51:35 +01:00
fprintf(output, _(" \\dn[S+] [PATTERN] list schemas\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\do[S] [PATTERN] list operators\n"));
DDL support for collations - collowner field - CREATE COLLATION - ALTER COLLATION - DROP COLLATION - COMMENT ON COLLATION - integration with extensions - pg_dump support for the above - dependency management - psql tab completion - psql \dO command
2011-02-12 14:54:13 +01:00
fprintf(output, _(" \\dO[S+] [PATTERN] list collations\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\dp [PATTERN] list table, view, and sequence access privileges\n"));
Message style fixes
2019-09-06 16:12:28 +02:00
fprintf(output, _(" \\dP[itn+] [PATTERN] list [only index/table] partitioned relations [n=nested]\n"));
Add the new psql command \drds to the psql docs, help and tab completion. I also thank Bernd Helmle for the documentation help on the previous settings patch, which I forgot on the commit message.
2009-10-08 18:34:01 +02:00
fprintf(output, _(" \\drds [PATRN1 [PATRN2]] list per-database role settings\n"));
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
fprintf(output, _(" \\dRp[+] [PATTERN] list replication publications\n"));
fprintf(output, _(" \\dRs[+] [PATTERN] list replication subscriptions\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\ds[S+] [PATTERN] list sequences\n"));
fprintf(output, _(" \\dt[S+] [PATTERN] list tables\n"));
fprintf(output, _(" \\dT[S+] [PATTERN] list data types\n"));
Reserve the "pg_" namespace for roles This will prevent users from creating roles which begin with "pg_" and will check for those roles before allowing an upgrade using pg_upgrade. This will allow for default roles to be provided at initdb time. Reviews by José Luis Tallón and Robert Haas
2016-04-08 22:56:27 +02:00
fprintf(output, _(" \\du[S+] [PATTERN] list roles\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\dv[S+] [PATTERN] list views\n"));
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
fprintf(output, _(" \\dx[+] [PATTERN] list extensions\n"));
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
fprintf(output, _(" \\dy [PATTERN] list event triggers\n"));
psql: Let \l accept a pattern reviewed by Satoshi Nagayasu
2013-03-04 04:17:08 +01:00
fprintf(output, _(" \\l[+] [PATTERN] list databases\n"));
Add psql \ev and \sv commands for editing and showing view definitions. These are basically just like the \ef and \sf commands for functions. Petr Korobeinikov, reviewed by Jeevan Chalke, some changes by me
2015-07-03 21:48:18 +02:00
fprintf(output, _(" \\sf[+] FUNCNAME show a function's definition\n"));
fprintf(output, _(" \\sv[+] VIEWNAME show a view's definition\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\z [PATTERN] same as \\dp\n"));
Apply message style guide to frontend programs.
2003-07-23 10:47:41 +02:00
fprintf(output, "\n");
Reorder psql \? help into groupings, idea from Harald Armin Massa.
2002-12-11 23:45:13 +01:00
fprintf(output, _("Formatting\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\a toggle between unaligned and aligned output mode\n"));
fprintf(output, _(" \\C [STRING] set table title, or unset if none\n"));
fprintf(output, _(" \\f [STRING] show or set field separator for unaligned query output\n"));
fprintf(output, _(" \\H toggle HTML output mode (currently %s)\n"),
Reorder psql \? help into groupings, idea from Harald Armin Massa.
2002-12-11 23:45:13 +01:00
ON(pset.popt.topt.format == PRINT_HTML));
psql: Fix \? output alignment This was inadvertently changed in commit c64e68fd.
2014-10-14 04:07:30 +02:00
fprintf(output, _(" \\pset [NAME [VALUE]] set table output option\n"
Add CSV table output mode in psql. "\pset format csv", or --csv, selects comma-separated values table format. This is compliant with RFC 4180, except that we aren't too picky about whether the record separator is LF or CRLF; also, the user may choose a field separator other than comma. This output format is directly compatible with the server's COPY CSV format, and will also be useful as input to other programs. It's considerably safer for that purpose than the old recommendation to use "unaligned" format, since the latter couldn't handle data containing the field separator character. Daniel Vérité, reviewed by Fabien Coelho and David Fetter, some tweaking by me Discussion: https://postgr.es/m/a8de371e-006f-4f92-ab72-2bbe3ee78f03@manitou-mail.org
2018-11-26 21:18:55 +01:00
" (border|columns|csv_fieldsep|expanded|fieldsep|\n"
" fieldsep_zero|footer|format|linestyle|null|\n"
" numericlocale|pager|pager_min_lines|recordsep|\n"
" recordsep_zero|tableattr|title|tuples_only|\n"
" unicode_border_linestyle|unicode_column_linestyle|\n"
" unicode_header_linestyle)\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\t [on|off] show only rows (currently %s)\n"),
Increment libpq major number for 7.3.1 and minor for 7.4.
2002-12-13 23:17:57 +01:00
ON(pset.popt.topt.tuples_only));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\T [STRING] set HTML <table> tag attributes, or unset if none\n"));
Add psql expanded auto mode This adds the "auto" option to the \x command, which switches to the expanded mode when the normal output would be wider than the screen. reviewed by Noah Misch
2011-11-12 16:03:10 +01:00
fprintf(output, _(" \\x [on|off|auto] toggle expanded output (currently %s)\n"),
Phase 3 of pgindent updates. Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
pset.popt.topt.expanded == 2 ? "auto" : ON(pset.popt.topt.expanded));
Apply message style guide to frontend programs.
2003-07-23 10:47:41 +02:00
fprintf(output, "\n");
psql cleanup
1999-11-05 00:14:30 +01:00
Reorgnize psql \? help output, to reduce the size of the "General" heading at the top; broken into more sections now.
2008-05-14 17:30:22 +02:00
fprintf(output, _("Connection\n"));
Make \? help message more clear when not connected. On second thought, "none" could mislead to think that you're connected a database with that name. Duplicate the whole string, so that it can be more easily translated. In back-branches, thought, just use an empty string in place of the database name, to avoid adding a translatable string.
2013-01-15 21:21:03 +01:00
if (currdb)
psql: fix \connect with URIs and conninfo strings This is the second try at this, after fcef1617295 failed miserably and had to be reverted: as it turns out, libpq cannot depend on libpgcommon after all. Instead of shuffling code in the master branch, make that one just like 9.4 and accept the duplication. (This was all my own mistake, not the patch submitter's). psql was already accepting conninfo strings as the first parameter in \connect, but the way it worked wasn't sane; some of the other parameters would get the previous connection's values, causing it to connect to a completely unexpected server or, more likely, not finding any server at all because of completely wrong combinations of parameters. Fix by explicitely checking for a conninfo-looking parameter in the dbname position; if one is found, use its complete specification rather than mix with the other arguments. Also, change tab-completion to not try to complete conninfo/URI-looking "dbnames" and document that conninfos are accepted as first argument. There was a weak consensus to backpatch this, because while the behavior of using the dbname as a conninfo is nowhere documented for \connect, it is reasonable to expect that it works because it does work in many other contexts. Therefore this is backpatched all the way back to 9.0. Author: David Fetter, Andrew Dunstan. Some editorialization by me (probably earning a Gierth's "Sloppy" badge in the process.) Reviewers: Andrew Gierth, Erik Rijkers, Pavel Stěhule, Stephen Frost, Robert Haas, Andrew Dunstan.
2015-04-02 17:30:57 +02:00
fprintf(output, _(" \\c[onnect] {[DBNAME|- USER|- HOST|- PORT|-] | conninfo}\n"
Make \? help message more clear when not connected. On second thought, "none" could mislead to think that you're connected a database with that name. Duplicate the whole string, so that it can be more easily translated. In back-branches, thought, just use an empty string in place of the database name, to avoid adding a translatable string.
2013-01-15 21:21:03 +01:00
" connect to new database (currently \"%s\")\n"),
currdb);
else
psql: fix \connect with URIs and conninfo strings This is the second try at this, after fcef1617295 failed miserably and had to be reverted: as it turns out, libpq cannot depend on libpgcommon after all. Instead of shuffling code in the master branch, make that one just like 9.4 and accept the duplication. (This was all my own mistake, not the patch submitter's). psql was already accepting conninfo strings as the first parameter in \connect, but the way it worked wasn't sane; some of the other parameters would get the previous connection's values, causing it to connect to a completely unexpected server or, more likely, not finding any server at all because of completely wrong combinations of parameters. Fix by explicitely checking for a conninfo-looking parameter in the dbname position; if one is found, use its complete specification rather than mix with the other arguments. Also, change tab-completion to not try to complete conninfo/URI-looking "dbnames" and document that conninfos are accepted as first argument. There was a weak consensus to backpatch this, because while the behavior of using the dbname as a conninfo is nowhere documented for \connect, it is reasonable to expect that it works because it does work in many other contexts. Therefore this is backpatched all the way back to 9.0. Author: David Fetter, Andrew Dunstan. Some editorialization by me (probably earning a Gierth's "Sloppy" badge in the process.) Reviewers: Andrew Gierth, Erik Rijkers, Pavel Stěhule, Stephen Frost, Robert Haas, Andrew Dunstan.
2015-04-02 17:30:57 +02:00
fprintf(output, _(" \\c[onnect] {[DBNAME|- USER|- HOST|- PORT|-] | conninfo}\n"
Create a psql command \gset to store query results into psql variables. This eases manipulation of query results in psql scripts. Pavel Stehule, reviewed by Piyush Newe, Shigeru Hanada, and Tom Lane
2013-02-02 23:06:38 +01:00
" connect to new database (currently no connection)\n"));
Put documentation of options and commands in more alphabetical order
2017-06-14 17:09:33 +02:00
fprintf(output, _(" \\conninfo display information about current connection\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\encoding [ENCODING] show or set client encoding\n"));
fprintf(output, _(" \\password [USERNAME] securely change the password for a user\n"));
Reorgnize psql \? help output, to reduce the size of the "General" heading at the top; broken into more sections now.
2008-05-14 17:30:22 +02:00
fprintf(output, "\n");
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _("Operating System\n"));
fprintf(output, _(" \\cd [DIR] change the current working directory\n"));
Add a \setenv command to psql. This can be used to set (or unset) environment variables that will affect programs called by psql (such as the PAGER), probably most usefully in a .psqlrc file. Andrew Dunstan, reviewed by Josh Kupershmidt.
2011-12-04 17:43:38 +01:00
fprintf(output, _(" \\setenv NAME [VALUE] set or unset environment variable\n"));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\timing [on|off] toggle timing of commands (currently %s)\n"),
Reorgnize psql \? help output, to reduce the size of the "General" heading at the top; broken into more sections now.
2008-05-14 17:30:22 +02:00
ON(pset.timing));
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _(" \\! [COMMAND] execute command in shell or start interactive shell\n"));
Reorgnize psql \? help output, to reduce the size of the "General" heading at the top; broken into more sections now.
2008-05-14 17:30:22 +02:00
fprintf(output, "\n");
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _("Variables\n"));
fprintf(output, _(" \\prompt [TEXT] NAME prompt user to set internal variable\n"));
fprintf(output, _(" \\set [NAME [VALUE]] set internal variable, or list all if no parameters\n"));
fprintf(output, _(" \\unset NAME unset (delete) internal variable\n"));
Reorgnize psql \? help output, to reduce the size of the "General" heading at the top; broken into more sections now.
2008-05-14 17:30:22 +02:00
fprintf(output, "\n");
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
fprintf(output, _("Large Objects\n"));
This makes help like this: \lo_export LOBOID FILE \lo_import FILE [COMMENT] \lo_list \lo_unlink LOBOID large object operations Instead of not saying anything about what arguments are required. Christopher Kings-Lynne
2003-12-01 23:34:48 +01:00
fprintf(output, _(" \\lo_export LOBOID FILE\n"
Clarify some strings
2004-11-09 15:39:44 +01:00
" \\lo_import FILE [COMMENT]\n"
Apply message style guide to frontend programs.
2003-07-23 10:47:41 +02:00
" \\lo_list\n"
In the \? output, align the columns consistently.
2009-03-25 14:14:17 +01:00
" \\lo_unlink LOBOID large object operations\n"));
Move psql \? Formatting above Large Object/Copy.
2002-12-12 00:07:06 +01:00
Clean up failure to use ClosePager() where appropriate in help.c. Also prevent possible repeat opening of pager in helpSQL().
2010-08-13 22:56:18 +02:00
ClosePager(output);
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
}
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
/*
* helpVariables
*
* show list of available variables (options) from command line
*/
void
helpVariables(unsigned short int pager)
{
FILE *output;
Rearrange the handling of error context reports. Remove the code in plpgsql that suppressed the innermost line of CONTEXT for messages emitted by RAISE commands. That was never more than a quick backwards-compatibility hack, and it's pretty silly in cases where the RAISE is nested in several levels of function. What's more, it violated our design theory that verbosity of error reports should be controlled on the client side not the server side. To alleviate the resulting noise increase, introduce a feature in libpq and psql whereby the CONTEXT field of messages can be suppressed, either always or only for non-error messages. Printing CONTEXT for errors only is now their default behavior. The actual code changes here are pretty small, but the effects on the regression test outputs are widespread. I had to edit some of the alternative expected outputs by hand; hopefully the buildfarm will soon find anything I fat-fingered. In passing, fix up (again) the output line counts in psql's various help displays. Add some commentary about how to verify them. Pavel Stehule, reviewed by Petr Jelínek, Jeevan Chalke, and others
2015-09-05 17:58:20 +02:00
/*
* Keep this line count in sync with the number of lines printed below!
* Use "psql --help=variables | wc" to count correctly; but notice that
* Windows builds currently print one more line than non-Windows builds.
* Using the larger number is fine.
*/
Add a "SQLSTATE-only" error verbosity option to libpq and psql. This is intended for use mostly in test scripts for external tools, which could do without cross-PG-version variations in error message wording. Of course, the SQLSTATE isn't guaranteed stable either, but it should be more so than the error message text. Note: there's a bit of an ABI change for libpq here, but it seems OK because if somebody compiles against a newer version of libpq-fe.h, and then tries to pass PQERRORS_SQLSTATE to PQsetErrorVerbosity() of an older libpq library, it will be accepted and then act like PQERRORS_DEFAULT, thanks to the way the tests in pqBuildErrorMessage3 have historically been phrased. That seems acceptable. Didier Gautheron, reviewed by Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/CAJRYxuKyj4zA+JGVrtx8OWAuBfE-_wN4sUMK4H49EuPed=mOBw@mail.gmail.com
2019-04-04 23:22:02 +02:00
output = PageOutput(158, pager ? &(pset.popt.topt) : NULL);
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
psql: Review of new help output strings
2015-12-20 17:50:04 +01:00
fprintf(output, _("List of specially treated variables\n\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _("psql variables:\n"));
fprintf(output, _("Usage:\n"));
psql: Review of new help output strings
2015-12-20 17:50:04 +01:00
fprintf(output, _(" psql --set=NAME=VALUE\n or \\set NAME VALUE inside psql\n\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
fprintf(output, _(" AUTOCOMMIT\n"
" if set, successful SQL commands are automatically committed\n"));
fprintf(output, _(" COMP_KEYWORD_CASE\n"
" determines the case used to complete SQL key words\n"
" [lower, upper, preserve-lower, preserve-upper]\n"));
fprintf(output, _(" DBNAME\n"
" the currently connected database name\n"));
fprintf(output, _(" ECHO\n"
" controls what input is written to standard output\n"
" [all, errors, none, queries]\n"));
fprintf(output, _(" ECHO_HIDDEN\n"
" if set, display internal queries executed by backslash commands;\n"
" if set to \"noexec\", just show them without execution\n"));
fprintf(output, _(" ENCODING\n"
" current client character set encoding\n"));
Add psql variables to track success/failure of SQL queries. This patch adds ERROR, SQLSTATE, and ROW_COUNT, which are updated after every query, as well as LAST_ERROR_MESSAGE and LAST_ERROR_SQLSTATE, which are updated only when a query fails. The expected usage of these is for scripting. Fabien Coelho, reviewed by Pavel Stehule Discussion: https://postgr.es/m/alpine.DEB.2.20.1704042158020.12290@lancre
2017-09-13 01:27:48 +02:00
fprintf(output, _(" ERROR\n"
" true if last query failed, else false\n"));
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
fprintf(output, _(" FETCH_COUNT\n"
" the number of result rows to fetch and display at a time (0 = unlimited)\n"));
tableam: introduce table AM infrastructure. This introduces the concept of table access methods, i.e. CREATE ACCESS METHOD ... TYPE TABLE and CREATE TABLE ... USING (storage-engine). No table access functionality is delegated to table AMs as of this commit, that'll be done in following commits. Subsequent commits will incrementally abstract table access functionality to be routed through table access methods. That change is too large to be reviewed & committed at once, so it'll be done incrementally. Docs will be updated at the end, as adding them incrementally would likely make them less coherent, and definitely is a lot more work, without a lot of benefit. Table access methods are specified similar to index access methods, i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with callbacks. In contrast to index AMs that struct needs to live as long as a backend, typically that's achieved by just returning a pointer to a constant struct. Psql's \d+ now displays a table's access method. That can be disabled with HIDE_TABLEAM=true, which is mainly useful so regression tests can be run against different AMs. It's quite possible that this behaviour still needs to be fine tuned. For now it's not allowed to set a table AM for a partitioned table, as we've not resolved how partitions would inherit that. Disallowing allows us to introduce, if we decide that's the way forward, such a behaviour without a compatibility break. Catversion bumped, to add the heap table AM and references to it. Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
fprintf(output, _(" HIDE_TABLEAM\n"
" if set, table access methods are not displayed\n"));
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
fprintf(output, _(" HISTCONTROL\n"
" controls command history [ignorespace, ignoredups, ignoreboth]\n"));
fprintf(output, _(" HISTFILE\n"
" file name used to store the command history\n"));
fprintf(output, _(" HISTSIZE\n"
Message style improvements Fix one untranslatable string concatenation in pg_rewind. Fix one message in pg_verify_checksums to use a style use elsewhere and avoid plural issues. Fix one gratuitous abbreviation in psql.
2018-09-13 23:35:43 +02:00
" maximum number of commands to store in the command history\n"));
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
fprintf(output, _(" HOST\n"
" the currently connected database server host\n"));
fprintf(output, _(" IGNOREEOF\n"
" number of EOFs needed to terminate an interactive session\n"));
fprintf(output, _(" LASTOID\n"
" value of the last affected OID\n"));
Add psql variables to track success/failure of SQL queries. This patch adds ERROR, SQLSTATE, and ROW_COUNT, which are updated after every query, as well as LAST_ERROR_MESSAGE and LAST_ERROR_SQLSTATE, which are updated only when a query fails. The expected usage of these is for scripting. Fabien Coelho, reviewed by Pavel Stehule Discussion: https://postgr.es/m/alpine.DEB.2.20.1704042158020.12290@lancre
2017-09-13 01:27:48 +02:00
fprintf(output, _(" LAST_ERROR_MESSAGE\n"
" LAST_ERROR_SQLSTATE\n"
" message and SQLSTATE of last error, or empty string and \"00000\" if none\n"));
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
fprintf(output, _(" ON_ERROR_ROLLBACK\n"
" if set, an error doesn't stop a transaction (uses implicit savepoints)\n"));
fprintf(output, _(" ON_ERROR_STOP\n"
" stop batch execution after error\n"));
fprintf(output, _(" PORT\n"
" server port of the current connection\n"));
fprintf(output, _(" PROMPT1\n"
" specifies the standard psql prompt\n"));
fprintf(output, _(" PROMPT2\n"
" specifies the prompt used when a statement continues from a previous line\n"));
fprintf(output, _(" PROMPT3\n"
" specifies the prompt used during COPY ... FROM STDIN\n"));
fprintf(output, _(" QUIET\n"
" run quietly (same as -q option)\n"));
Add psql variables to track success/failure of SQL queries. This patch adds ERROR, SQLSTATE, and ROW_COUNT, which are updated after every query, as well as LAST_ERROR_MESSAGE and LAST_ERROR_SQLSTATE, which are updated only when a query fails. The expected usage of these is for scripting. Fabien Coelho, reviewed by Pavel Stehule Discussion: https://postgr.es/m/alpine.DEB.2.20.1704042158020.12290@lancre
2017-09-13 01:27:48 +02:00
fprintf(output, _(" ROW_COUNT\n"
" number of rows returned or affected by last query, or 0\n"));
Add psql variables showing server version and psql version. We already had a psql variable VERSION that shows the verbose form of psql's own version. Add VERSION_NAME to show the short form (e.g., "11devel") and VERSION_NUM to show the numeric form (e.g., 110000). Also add SERVER_VERSION_NAME and SERVER_VERSION_NUM to show the short and numeric forms of the server's version. (We'd probably add SERVER_VERSION with the verbose string if it were readily available; but adding another network round trip to get it seems too expensive.) The numeric forms, in particular, are expected to be useful for scripting purposes, now that psql can do conditional tests. Fabien Coelho, reviewed by Pavel Stehule Discussion: https://postgr.es/m/alpine.DEB.2.20.1704020917220.4632@lancre
2017-09-05 16:51:36 +02:00
fprintf(output, _(" SERVER_VERSION_NAME\n"
" SERVER_VERSION_NUM\n"
" server's version (in short string or numeric format)\n"));
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
fprintf(output, _(" SHOW_CONTEXT\n"
" controls display of message context fields [never, errors, always]\n"));
fprintf(output, _(" SINGLELINE\n"
" if set, end of line terminates SQL commands (same as -S option)\n"));
fprintf(output, _(" SINGLESTEP\n"
" single-step mode (same as -s option)\n"));
Add psql variables to track success/failure of SQL queries. This patch adds ERROR, SQLSTATE, and ROW_COUNT, which are updated after every query, as well as LAST_ERROR_MESSAGE and LAST_ERROR_SQLSTATE, which are updated only when a query fails. The expected usage of these is for scripting. Fabien Coelho, reviewed by Pavel Stehule Discussion: https://postgr.es/m/alpine.DEB.2.20.1704042158020.12290@lancre
2017-09-13 01:27:48 +02:00
fprintf(output, _(" SQLSTATE\n"
" SQLSTATE of last query, or \"00000\" if no error\n"));
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
fprintf(output, _(" USER\n"
" the currently connected database user\n"));
fprintf(output, _(" VERBOSITY\n"
Add a "SQLSTATE-only" error verbosity option to libpq and psql. This is intended for use mostly in test scripts for external tools, which could do without cross-PG-version variations in error message wording. Of course, the SQLSTATE isn't guaranteed stable either, but it should be more so than the error message text. Note: there's a bit of an ABI change for libpq here, but it seems OK because if somebody compiles against a newer version of libpq-fe.h, and then tries to pass PQERRORS_SQLSTATE to PQsetErrorVerbosity() of an older libpq library, it will be accepted and then act like PQERRORS_DEFAULT, thanks to the way the tests in pqBuildErrorMessage3 have historically been phrased. That seems acceptable. Didier Gautheron, reviewed by Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/CAJRYxuKyj4zA+JGVrtx8OWAuBfE-_wN4sUMK4H49EuPed=mOBw@mail.gmail.com
2019-04-04 23:22:02 +02:00
" controls verbosity of error reports [default, verbose, terse, sqlstate]\n"));
Add psql variables showing server version and psql version. We already had a psql variable VERSION that shows the verbose form of psql's own version. Add VERSION_NAME to show the short form (e.g., "11devel") and VERSION_NUM to show the numeric form (e.g., 110000). Also add SERVER_VERSION_NAME and SERVER_VERSION_NUM to show the short and numeric forms of the server's version. (We'd probably add SERVER_VERSION with the verbose string if it were readily available; but adding another network round trip to get it seems too expensive.) The numeric forms, in particular, are expected to be useful for scripting purposes, now that psql can do conditional tests. Fabien Coelho, reviewed by Pavel Stehule Discussion: https://postgr.es/m/alpine.DEB.2.20.1704020917220.4632@lancre
2017-09-05 16:51:36 +02:00
fprintf(output, _(" VERSION\n"
" VERSION_NAME\n"
" VERSION_NUM\n"
" psql's version (in verbose string, short string, or numeric format)\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
psql: Review of new help output strings
2015-12-20 17:50:04 +01:00
fprintf(output, _("\nDisplay settings:\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _("Usage:\n"));
psql: Review of new help output strings
2015-12-20 17:50:04 +01:00
fprintf(output, _(" psql --pset=NAME[=VALUE]\n or \\pset NAME [VALUE] inside psql\n\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
fprintf(output, _(" border\n"
" border style (number)\n"));
fprintf(output, _(" columns\n"
" target width for the wrapped format\n"));
fprintf(output, _(" expanded (or x)\n"
" expanded output [on, off, auto]\n"));
fprintf(output, _(" fieldsep\n"
" field separator for unaligned output (default \"%s\")\n"),
DEFAULT_FIELD_SEP);
fprintf(output, _(" fieldsep_zero\n"
" set field separator for unaligned output to a zero byte\n"));
fprintf(output, _(" footer\n"
" enable or disable display of the table footer [on, off]\n"));
fprintf(output, _(" format\n"
" set output format [unaligned, aligned, wrapped, html, asciidoc, ...]\n"));
fprintf(output, _(" linestyle\n"
" set the border line drawing style [ascii, old-ascii, unicode]\n"));
fprintf(output, _(" null\n"
" set the string to be printed in place of a null value\n"));
fprintf(output, _(" numericlocale\n"
" enable display of a locale-specific character to separate groups of digits\n"));
fprintf(output, _(" pager\n"
" control when an external pager is used [yes, no, always]\n"));
fprintf(output, _(" recordsep\n"
" record (line) separator for unaligned output\n"));
fprintf(output, _(" recordsep_zero\n"
" set record separator for unaligned output to a zero byte\n"));
fprintf(output, _(" tableattr (or T)\n"
" specify attributes for table tag in html format, or proportional\n"
" column widths for left-aligned data types in latex-longtable format\n"));
fprintf(output, _(" title\n"
" set the table title for subsequently printed tables\n"));
fprintf(output, _(" tuples_only\n"
" if set, only actual table data is shown\n"));
psql: Review of new help output strings
2015-12-20 17:50:04 +01:00
fprintf(output, _(" unicode_border_linestyle\n"
" unicode_column_linestyle\n"
" unicode_header_linestyle\n"
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
" set the style of Unicode line drawing [single, double]\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _("\nEnvironment variables:\n"));
fprintf(output, _("Usage:\n"));
#ifndef WIN32
psql: Review of new help output strings
2015-12-20 17:50:04 +01:00
fprintf(output, _(" NAME=VALUE [NAME=VALUE] psql ...\n or \\setenv NAME [VALUE] inside psql\n\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
#else
psql: Review of new help output strings
2015-12-20 17:50:04 +01:00
fprintf(output, _(" set NAME=VALUE\n psql ...\n or \\setenv NAME [VALUE] inside psql\n\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
#endif
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
fprintf(output, _(" COLUMNS\n"
" number of columns for wrapped format\n"));
fprintf(output, _(" PGAPPNAME\n"
" same as the application_name connection parameter\n"));
fprintf(output, _(" PGDATABASE\n"
" same as the dbname connection parameter\n"));
fprintf(output, _(" PGHOST\n"
" same as the host connection parameter\n"));
fprintf(output, _(" PGPASSWORD\n"
" connection password (not recommended)\n"));
fprintf(output, _(" PGPASSFILE\n"
" password file name\n"));
fprintf(output, _(" PGPORT\n"
" same as the port connection parameter\n"));
fprintf(output, _(" PGUSER\n"
" same as the user connection parameter\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" PSQL_EDITOR, EDITOR, VISUAL\n"
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
" editor used by the \\e, \\ef, and \\ev commands\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
fprintf(output, _(" PSQL_EDITOR_LINENUMBER_ARG\n"
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
" how to specify a line number when invoking the editor\n"));
fprintf(output, _(" PSQL_HISTORY\n"
" alternative location for the command history file\n"));
In psql, use PSQL_PAGER in preference to PAGER, if it's set. This allows the user's environment to set up a psql-specific choice of pager, in much the same way that we provide PSQL_EDITOR to allow a psql-specific override of the more widely known EDITOR variable. Pavel Stehule, reviewed by Thomas Munro Discussion: https://postgr.es/m/CAFj8pRD3RRk9S1eRbnGm_T6brc3Ss5mohraNzTSJquzx+pmtKA@mail.gmail.com
2017-09-05 18:02:06 +02:00
fprintf(output, _(" PSQL_PAGER, PAGER\n"
" name of external pager program\n"));
Reformat psql's --help=variables output. The previous format with variable names and descriptions in separate columns was extremely constraining about the length of the descriptions. We'd dealt with that in several inconsistent ways over the years, including letting the lines run over 80 characters, breaking descriptions into multiple lines, or shoving the description onto a separate line. But it's been a long time since the output could realistically fit onto a single screen vertically, so let's just rely even more heavily on the pager to deal with the vertical distance, and split each entry into two (or more) lines, in the format variable-name variable description goes here Each variable name + description remains a single translatable string, in hopes of reducing translator confusion; we're just changing the embedded whitespace. I failed to resist the temptation to copy-edit one or two of the descriptions while at it. Discussion: https://postgr.es/m/2947.1504542679@sss.pgh.pa.us
2017-09-05 16:17:10 +02:00
fprintf(output, _(" PSQLRC\n"
" alternative location for the user's .psqlrc file\n"));
fprintf(output, _(" SHELL\n"
" shell used by the \\! command\n"));
fprintf(output, _(" TMPDIR\n"
" directory for temporary files\n"));
Add new psql help topics, accessible to both --help and \?. Add --help=<topic> for the commandline, and \? <topic> as a backslash command, to show more help than the invocations without parameters do. "commands", "variables" and "options" currently exist as help topics describing, respectively, backslash commands, psql variables, and commandline switches. Without parameters the help commands show their previous topic. Some further wordsmithing or extending of the added help content might be needed; but there seems little benefit delaying the overall feature further. Author: Pavel Stehule, editorialized by many Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit Menon-Sen and Erik Rijkers. Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=2YQ0s2Q@mail.gmail.com, CAFj8pRA54AbTv2RXDTRxiAd8hy8wxmoVLqhJDRCwEnhdd7OUkw@mail.gmail.com
2014-09-09 22:19:14 +02:00
ClosePager(output);
}
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
/*
* helpSQL -- help with SQL commands
*
Work around a subtle portability problem in use of printf %s format. Depending on which spec you read, field widths and precisions in %s may be counted either in bytes or characters. Our code was assuming bytes, which is wrong at least for glibc's implementation, and in any case libc might have a different idea of the prevailing encoding than we do. Hence, for portable results we must avoid using anything more complex than just "%s" unless the string to be printed is known to be all-ASCII. This patch fixes the cases I could find, including the psql formatting failure reported by Hernan Gonzalez. In HEAD only, I also added comments to some places where it appears safe to continue using "%.*s".
2010-05-08 18:39:53 +02:00
* Note: we assume caller removed any trailing spaces in "topic".
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
*/
void
Make the printing code somewhat more independent by not relying on functions and global variables from the rest of psql. Also clean up some data type mismatches created by the last pager patch.
2003-03-18 23:15:44 +01:00
helpSQL(const char *topic, unsigned short int pager)
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
{
Fixed psql double quoting of SQL ids Fixed libpq printing functions
2000-02-08 00:10:11 +01:00
#define VALUE_OR_NULL(a) ((a) ? (a) : "")
psql cleanup
1999-11-05 00:14:30 +01:00
if (!topic || strlen(topic) == 0)
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
{
Fix psql \h output for case of no parameters (ie, list all the known commands) to format properly for the actually needed column width, instead of having a hard-wired assumption about the longest command name length. Also make it respond to the current screen width. In passing, const-ify the constant table.
2008-01-20 22:13:55 +01:00
/* Print all the available command names */
int screen_width;
int ncolumns;
int nrows;
pgindent run.
2003-08-04 02:43:34 +02:00
FILE *output;
Fix psql \h output for case of no parameters (ie, list all the known commands) to format properly for the actually needed column width, instead of having a hard-wired assumption about the longest command name length. Also make it respond to the current screen width. In passing, const-ify the constant table.
2008-01-20 22:13:55 +01:00
int i;
int j;
Page \h output and centralize psql paging code in PageOutput().
2002-10-23 21:23:57 +02:00
Fix psql \h output for case of no parameters (ie, list all the known commands) to format properly for the actually needed column width, instead of having a hard-wired assumption about the longest command name length. Also make it respond to the current screen width. In passing, const-ify the constant table.
2008-01-20 22:13:55 +01:00
#ifdef TIOCGWINSZ
struct winsize screen_size;
if (ioctl(fileno(stdout), TIOCGWINSZ, &screen_size) == -1)
screen_width = 80; /* ioctl failed, assume 80 */
else
screen_width = screen_size.ws_col;
#else
screen_width = 80; /* default assumption */
#endif
ncolumns = (screen_width - 3) / (QL_MAX_CMD_LEN + 1);
ncolumns = Max(ncolumns, 1);
nrows = (QL_HELP_COUNT + (ncolumns - 1)) / ncolumns;
Add a pager_min_lines setting to psql If set, the pager will not be used unless this many lines are to be displayed, even if that is more than the screen depth. Default is zero, meaning it's disabled. There is probably more work to be done in giving the user control over when the pager is used, particularly when wide output forces use of the pager regardless of how many lines there are, but this is a start.
2015-03-28 16:07:41 +01:00
output = PageOutput(nrows + 1, pager ? &(pset.popt.topt) : NULL);
psql cleanup
1999-11-05 00:14:30 +01:00
Page \h output and centralize psql paging code in PageOutput().
2002-10-23 21:23:57 +02:00
fputs(_("Available help:\n"), output);
psql cleanup
1999-11-05 00:14:30 +01:00
Fix psql \h output for case of no parameters (ie, list all the known commands) to format properly for the actually needed column width, instead of having a hard-wired assumption about the longest command name length. Also make it respond to the current screen width. In passing, const-ify the constant table.
2008-01-20 22:13:55 +01:00
for (i = 0; i < nrows; i++)
psql cleanup
1999-11-05 00:14:30 +01:00
{
Fix psql \h output for case of no parameters (ie, list all the known commands) to format properly for the actually needed column width, instead of having a hard-wired assumption about the longest command name length. Also make it respond to the current screen width. In passing, const-ify the constant table.
2008-01-20 22:13:55 +01:00
fprintf(output, " ");
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
for (j = 0; j < ncolumns - 1; j++)
Fix psql \h output for case of no parameters (ie, list all the known commands) to format properly for the actually needed column width, instead of having a hard-wired assumption about the longest command name length. Also make it respond to the current screen width. In passing, const-ify the constant table.
2008-01-20 22:13:55 +01:00
fprintf(output, "%-*s",
QL_MAX_CMD_LEN + 1,
VALUE_OR_NULL(QL_HELP[i + j * nrows].cmd));
if (i + j * nrows < QL_HELP_COUNT)
fprintf(output, "%s",
VALUE_OR_NULL(QL_HELP[i + j * nrows].cmd));
Page \h output and centralize psql paging code in PageOutput().
2002-10-23 21:23:57 +02:00
fputc('\n', output);
}
Fix psql \h output for case of no parameters (ie, list all the known commands) to format properly for the actually needed column width, instead of having a hard-wired assumption about the longest command name length. Also make it respond to the current screen width. In passing, const-ify the constant table.
2008-01-20 22:13:55 +01:00
Clean up failure to use ClosePager() where appropriate in help.c. Also prevent possible repeat opening of pager in helpSQL().
2010-08-13 22:56:18 +02:00
ClosePager(output);
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
}
psql cleanup
1999-11-05 00:14:30 +01:00
else
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
int i,
j,
x = 0;
psql cleanup
1999-11-05 00:14:30 +01:00
bool help_found = false;
Clean up failure to use ClosePager() where appropriate in help.c. Also prevent possible repeat opening of pager in helpSQL().
2010-08-13 22:56:18 +02:00
FILE *output = NULL;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
size_t len,
wordlen;
seemed like a typo in one of the appendix tables Robert Treat
2003-09-11 18:22:42 +02:00
int nl_count = 0;
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Work around a subtle portability problem in use of printf %s format. Depending on which spec you read, field widths and precisions in %s may be counted either in bytes or characters. Our code was assuming bytes, which is wrong at least for glibc's implementation, and in any case libc might have a different idea of the prevailing encoding than we do. Hence, for portable results we must avoid using anything more complex than just "%s" unless the string to be printed is known to be all-ASCII. This patch fixes the cases I could find, including the psql formatting failure reported by Hernan Gonzalez. In HEAD only, I also added comments to some places where it appears safe to continue using "%.*s".
2010-05-08 18:39:53 +02:00
/*
* We first try exact match, then first + second words, then first
* word only.
*/
/home/peter/commit-msg
2000-05-12 18:13:44 +02:00
len = strlen(topic);
seemed like a typo in one of the appendix tables Robert Treat
2003-09-11 18:22:42 +02:00
Work around a subtle portability problem in use of printf %s format. Depending on which spec you read, field widths and precisions in %s may be counted either in bytes or characters. Our code was assuming bytes, which is wrong at least for glibc's implementation, and in any case libc might have a different idea of the prevailing encoding than we do. Hence, for portable results we must avoid using anything more complex than just "%s" unless the string to be printed is known to be all-ASCII. This patch fixes the cases I could find, including the psql formatting failure reported by Hernan Gonzalez. In HEAD only, I also added comments to some places where it appears safe to continue using "%.*s".
2010-05-08 18:39:53 +02:00
for (x = 1; x <= 3; x++)
psql cleanup
1999-11-05 00:14:30 +01:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
if (x > 1) /* Nothing on first pass - try the opening
Work around a subtle portability problem in use of printf %s format. Depending on which spec you read, field widths and precisions in %s may be counted either in bytes or characters. Our code was assuming bytes, which is wrong at least for glibc's implementation, and in any case libc might have a different idea of the prevailing encoding than we do. Hence, for portable results we must avoid using anything more complex than just "%s" unless the string to be printed is known to be all-ASCII. This patch fixes the cases I could find, including the psql formatting failure reported by Hernan Gonzalez. In HEAD only, I also added comments to some places where it appears safe to continue using "%.*s".
2010-05-08 18:39:53 +02:00
* word(s) */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
{
wordlen = j = 1;
while (topic[j] != ' ' && j++ < len)
wordlen++;
if (x == 2)
Attached is a patch that enhances the "\h" capability in psql. I often find myself typing a command and then wanting to get the syntax for it. So I do a ctrl-a and add a \h: but psql does not recognize the command, because I have stuff attached to it (e.g. "alter table foobar"), so I have to scroll over and delete everything except the name of the command itself. This patch gives \h three chances to match: if nothing matches the complete string (current behavior), it tries to match the first two words (e.g. "ALTER TABLE"). If that fails, it tries to match the first word (e.g. "DELETE"). Greg Sabino Mullane
2005-07-06 05:14:48 +02:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
j++;
while (topic[j] != ' ' && j++ <= len)
wordlen++;
Attached is a patch that enhances the "\h" capability in psql. I often find myself typing a command and then wanting to get the syntax for it. So I do a ctrl-a and add a \h: but psql does not recognize the command, because I have stuff attached to it (e.g. "alter table foobar"), so I have to scroll over and delete everything except the name of the command itself. This patch gives \h three chances to match: if nothing matches the complete string (current behavior), it tries to match the first two words (e.g. "ALTER TABLE"). If that fails, it tries to match the first word (e.g. "DELETE"). Greg Sabino Mullane
2005-07-06 05:14:48 +02:00
}
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
if (wordlen >= len) /* Don't try again if the same word */
Attached is a patch that enhances the "\h" capability in psql. I often find myself typing a command and then wanting to get the syntax for it. So I do a ctrl-a and add a \h: but psql does not recognize the command, because I have stuff attached to it (e.g. "alter table foobar"), so I have to scroll over and delete everything except the name of the command itself. This patch gives \h three chances to match: if nothing matches the complete string (current behavior), it tries to match the first two words (e.g. "ALTER TABLE"). If that fails, it tries to match the first word (e.g. "DELETE"). Greg Sabino Mullane
2005-07-06 05:14:48 +02:00
{
Clean up failure to use ClosePager() where appropriate in help.c. Also prevent possible repeat opening of pager in helpSQL().
2010-08-13 22:56:18 +02:00
if (!output)
Add a pager_min_lines setting to psql If set, the pager will not be used unless this many lines are to be displayed, even if that is more than the screen depth. Default is zero, meaning it's disabled. There is probably more work to be done in giving the user control over when the pager is used, particularly when wide output forces use of the pager regardless of how many lines there are, but this is a start.
2015-03-28 16:07:41 +01:00
output = PageOutput(nl_count, pager ? &(pset.popt.topt) : NULL);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
break;
Attached is a patch that enhances the "\h" capability in psql. I often find myself typing a command and then wanting to get the syntax for it. So I do a ctrl-a and add a \h: but psql does not recognize the command, because I have stuff attached to it (e.g. "alter table foobar"), so I have to scroll over and delete everything except the name of the command itself. This patch gives \h three chances to match: if nothing matches the complete string (current behavior), it tries to match the first two words (e.g. "ALTER TABLE"). If that fails, it tries to match the first word (e.g. "DELETE"). Greg Sabino Mullane
2005-07-06 05:14:48 +02:00
}
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
len = wordlen;
}
/* Count newlines for pager */
for (i = 0; QL_HELP[i].cmd; i++)
{
if (pg_strncasecmp(topic, QL_HELP[i].cmd, len) == 0 ||
strcmp(topic, "*") == 0)
Attached is a patch that enhances the "\h" capability in psql. I often find myself typing a command and then wanting to get the syntax for it. So I do a ctrl-a and add a \h: but psql does not recognize the command, because I have stuff attached to it (e.g. "alter table foobar"), so I have to scroll over and delete everything except the name of the command itself. This patch gives \h three chances to match: if nothing matches the complete string (current behavior), it tries to match the first two words (e.g. "ALTER TABLE"). If that fails, it tries to match the first word (e.g. "DELETE"). Greg Sabino Mullane
2005-07-06 05:14:48 +02:00
{
Easier to translate psql help Instead of requiring translators to translate the entire SQL command synopses, change create_help.pl to only require them to translate the placeholders, and paste those into the synopsis using a printf mechanism. Make some small updates to the markup to make it easier to parse. Note: This causes msgmerge of gettext 0.17 to segfault. You will need the patch from https://savannah.gnu.org/bugs/?27474 to make it work. msgmerge usually only runs on babel.postgresql.org, however.
2009-09-18 07:00:42 +02:00
nl_count += 5 + QL_HELP[i].nl_count;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
/* If we have an exact match, exit. Fixes \h SELECT */
if (pg_strcasecmp(topic, QL_HELP[i].cmd) == 0)
break;
Attached is a patch that enhances the "\h" capability in psql. I often find myself typing a command and then wanting to get the syntax for it. So I do a ctrl-a and add a \h: but psql does not recognize the command, because I have stuff attached to it (e.g. "alter table foobar"), so I have to scroll over and delete everything except the name of the command itself. This patch gives \h three chances to match: if nothing matches the complete string (current behavior), it tries to match the first two words (e.g. "ALTER TABLE"). If that fails, it tries to match the first word (e.g. "DELETE"). Greg Sabino Mullane
2005-07-06 05:14:48 +02:00
}
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
}
Clean up failure to use ClosePager() where appropriate in help.c. Also prevent possible repeat opening of pager in helpSQL().
2010-08-13 22:56:18 +02:00
if (!output)
Add a pager_min_lines setting to psql If set, the pager will not be used unless this many lines are to be displayed, even if that is more than the screen depth. Default is zero, meaning it's disabled. There is probably more work to be done in giving the user control over when the pager is used, particularly when wide output forces use of the pager regardless of how many lines there are, but this is a start.
2015-03-28 16:07:41 +01:00
output = PageOutput(nl_count, pager ? &(pset.popt.topt) : NULL);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
for (i = 0; QL_HELP[i].cmd; i++)
{
if (pg_strncasecmp(topic, QL_HELP[i].cmd, len) == 0 ||
strcmp(topic, "*") == 0)
{
Easier to translate psql help Instead of requiring translators to translate the entire SQL command synopses, change create_help.pl to only require them to translate the placeholders, and paste those into the synopsis using a printf mechanism. Make some small updates to the markup to make it easier to parse. Note: This causes msgmerge of gettext 0.17 to segfault. You will need the patch from https://savannah.gnu.org/bugs/?27474 to make it work. msgmerge usually only runs on babel.postgresql.org, however.
2009-09-18 07:00:42 +02:00
PQExpBufferData buffer;
psql: Add documentation URL to \help output Add a link to the specific command's reference web page to the bottom of its \help output. Discussion: https://www.postgresql.org/message-id/flat/40179bd0-fa7d-4108-1991-a20ae9ad5667%402ndquadrant.com
2019-03-11 08:50:02 +01:00
char *url;
Easier to translate psql help Instead of requiring translators to translate the entire SQL command synopses, change create_help.pl to only require them to translate the placeholders, and paste those into the synopsis using a printf mechanism. Make some small updates to the markup to make it easier to parse. Note: This causes msgmerge of gettext 0.17 to segfault. You will need the patch from https://savannah.gnu.org/bugs/?27474 to make it work. msgmerge usually only runs on babel.postgresql.org, however.
2009-09-18 07:00:42 +02:00
initPQExpBuffer(&buffer);
QL_HELP[i].syntaxfunc(&buffer);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
help_found = true;
psql: Add documentation URL to \help output Add a link to the specific command's reference web page to the bottom of its \help output. Discussion: https://www.postgresql.org/message-id/flat/40179bd0-fa7d-4108-1991-a20ae9ad5667%402ndquadrant.com
2019-03-11 08:50:02 +01:00
url = psprintf("https://www.postgresql.org/docs/%s/%s.html",
strstr(PG_VERSION, "devel") ? "devel" : PG_MAJORVERSION,
QL_HELP[i].docbook_id);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
fprintf(output, _("Command: %s\n"
"Description: %s\n"
psql: Add documentation URL to \help output Add a link to the specific command's reference web page to the bottom of its \help output. Discussion: https://www.postgresql.org/message-id/flat/40179bd0-fa7d-4108-1991-a20ae9ad5667%402ndquadrant.com
2019-03-11 08:50:02 +01:00
"Syntax:\n%s\n\n"
"URL: %s\n\n"),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
QL_HELP[i].cmd,
_(QL_HELP[i].help),
psql: Add documentation URL to \help output Add a link to the specific command's reference web page to the bottom of its \help output. Discussion: https://www.postgresql.org/message-id/flat/40179bd0-fa7d-4108-1991-a20ae9ad5667%402ndquadrant.com
2019-03-11 08:50:02 +01:00
buffer.data,
url);
free(url);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
/* If we have an exact match, exit. Fixes \h SELECT */
if (pg_strcasecmp(topic, QL_HELP[i].cmd) == 0)
Attached is a patch that enhances the "\h" capability in psql. I often find myself typing a command and then wanting to get the syntax for it. So I do a ctrl-a and add a \h: but psql does not recognize the command, because I have stuff attached to it (e.g. "alter table foobar"), so I have to scroll over and delete everything except the name of the command itself. This patch gives \h three chances to match: if nothing matches the complete string (current behavior), it tries to match the first two words (e.g. "ALTER TABLE"). If that fails, it tries to match the first word (e.g. "DELETE"). Greg Sabino Mullane
2005-07-06 05:14:48 +02:00
break;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
}
}
if (help_found) /* Don't keep trying if we got a match */
break;
psql cleanup
1999-11-05 00:14:30 +01:00
}
if (!help_found)
Work around a subtle portability problem in use of printf %s format. Depending on which spec you read, field widths and precisions in %s may be counted either in bytes or characters. Our code was assuming bytes, which is wrong at least for glibc's implementation, and in any case libc might have a different idea of the prevailing encoding than we do. Hence, for portable results we must avoid using anything more complex than just "%s" unless the string to be printed is known to be all-ASCII. This patch fixes the cases I could find, including the psql formatting failure reported by Hernan Gonzalez. In HEAD only, I also added comments to some places where it appears safe to continue using "%.*s".
2010-05-08 18:39:53 +02:00
fprintf(output, _("No help available for \"%s\".\nTry \\h with no arguments to see available help.\n"), topic);
seemed like a typo in one of the appendix tables Robert Treat
2003-09-11 18:22:42 +02:00
Clean up failure to use ClosePager() where appropriate in help.c. Also prevent possible repeat opening of pager in helpSQL().
2010-08-13 22:56:18 +02:00
ClosePager(output);
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
}
}
void
print_copyright(void)
{
Clean up newlines following left parentheses We used to strategically place newlines after some function call left parentheses to make pgindent move the argument list a few chars to the left, so that the whole line would fit under 80 chars. However, pgindent no longer does that, so the newlines just made the code vertically longer for no reason. Remove those newlines, and reflow some of those lines for some extra naturality. Reviewed-by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20200129200401.GA6303@alvherre.pgsql
2020-01-30 17:42:14 +01:00
puts("PostgreSQL Database Management System\n"
Update psql's \copyright to match the text we have in the COPYRIGHT file.
2011-01-27 19:20:08 +01:00
"(formerly known as Postgres, then as Postgres95)\n\n"
Update copyrights for 2020 Backpatch-through: update all files in master, backpatch legal files through 9.4
2020-01-01 18:21:45 +01:00
"Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group\n\n"
Update psql's \copyright to match the text we have in the COPYRIGHT file.
2011-01-27 19:20:08 +01:00
"Portions Copyright (c) 1994, The Regents of the University of California\n\n"
Phase 3 of pgindent updates. Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
"Permission to use, copy, modify, and distribute this software and its\n"
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
"documentation for any purpose, without fee, and without a written agreement\n"
Phase 3 of pgindent updates. Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
"is hereby granted, provided that the above copyright notice and this\n"
"paragraph and the following two paragraphs appear in all copies.\n\n"
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
"IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR\n"
Update psql's \copyright to match the text we have in the COPYRIGHT file.
2011-01-27 19:20:08 +01:00
"DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING\n"
"LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS\n"
"DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE\n"
"POSSIBILITY OF SUCH DAMAGE.\n\n"
Phase 3 of pgindent updates. Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
"THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,\n"
Update psql's \copyright to match the text we have in the COPYRIGHT file.
2011-01-27 19:20:08 +01:00
"INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY\n"
"AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS\n"
"ON AN \"AS IS\" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO\n"
Clean up newlines following left parentheses We used to strategically place newlines after some function call left parentheses to make pgindent move the argument list a few chars to the left, so that the whole line would fit under 80 chars. However, pgindent no longer does that, so the newlines just made the code vertically longer for no reason. Remove those newlines, and reflow some of those lines for some extra naturality. Reviewed-by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20200129200401.GA6303@alvherre.pgsql
2020-01-30 17:42:14 +01:00
"PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.\n");
Major psql overhaul by Peter Eisentraut.
1999-11-04 22:56:02 +01:00
}