2000-01-19 00:30:24 +01:00
|
|
|
/*
|
|
|
|
* psql - the PostgreSQL interactive terminal
|
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Copyright (c) 2000-2023, PostgreSQL Global Development Group
|
2000-01-19 00:30:24 +01:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/bin/psql/common.c
|
2000-01-19 00:30:24 +01:00
|
|
|
*/
|
2001-02-10 03:31:31 +01:00
|
|
|
#include "postgres_fe.h"
|
1999-11-04 22:56:02 +01:00
|
|
|
|
2003-06-28 02:12:40 +02:00
|
|
|
#include <ctype.h>
|
Fix behavior of printTable() and friends with externally-invoked pager.
The formatting modes that depend on knowledge of the terminal window width
did not work right when printing a query result that's been fetched in
sections (as a result of FETCH_SIZE). ExecQueryUsingCursor() would force
use of the pager as soon as there's more than one result section, and then
print.c would see an output file pointer that's not stdout and incorrectly
conclude that the terminal window width isn't relevant.
This has been broken all along for non-expanded "wrapped" output format,
and as of 9.5 the issue affects expanded mode as well. The problem also
caused "\pset expanded auto" mode to invariably *not* switch to expanded
output in a segmented result, which seems to me to be exactly backwards.
To fix, we need to pass down an "is_pager" flag to inform the print.c
subroutines that some calling level has already replaced stdout with a
pager pipe, so they should (a) not do that again and (b) nonetheless honor
the window size. (Notably, this makes the first is_pager test in
print_aligned_text() not be dead code anymore.)
This patch is a bit invasive because there are so many existing calls of
printQuery()/printTable(), but fortunately all but a couple can just pass
"false" for the added parameter.
Back-patch to 9.5 but no further. Given the lack of field complaints,
it's not clear that we should change the behavior in stable branches.
Also, the API change for printQuery()/printTable() might possibly break
third-party code, again something we don't like to do in stable branches.
However, it's not quite too late to do this in 9.5, and with the larger
scope of the problem there, it seems worth doing.
2015-12-03 00:20:33 +01:00
|
|
|
#include <limits.h>
|
2016-09-03 21:29:03 +02:00
|
|
|
#include <math.h>
|
2022-01-11 19:46:12 +01:00
|
|
|
#include <pwd.h>
|
1999-11-04 22:56:02 +01:00
|
|
|
#include <signal.h>
|
|
|
|
#ifndef WIN32
|
1999-11-05 00:14:30 +01:00
|
|
|
#include <unistd.h> /* for write() */
|
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
|
|
|
#else
|
|
|
|
#include <io.h> /* for _write() */
|
2000-02-08 00:10:11 +01:00
|
|
|
#include <win32.h>
|
1999-11-04 22:56:02 +01:00
|
|
|
#endif
|
|
|
|
|
2003-06-28 02:12:40 +02:00
|
|
|
#include "command.h"
|
2019-05-14 20:19:49 +02:00
|
|
|
#include "common.h"
|
2019-10-23 06:08:53 +02:00
|
|
|
#include "common/logging.h"
|
1999-11-04 22:56:02 +01:00
|
|
|
#include "copy.h"
|
2016-04-09 01:23:18 +02:00
|
|
|
#include "crosstabview.h"
|
2019-12-02 03:18:56 +01:00
|
|
|
#include "fe_utils/cancel.h"
|
2019-10-23 06:08:53 +02:00
|
|
|
#include "fe_utils/mbprint.h"
|
|
|
|
#include "fe_utils/string_utils.h"
|
|
|
|
#include "portability/instr_time.h"
|
2019-05-14 20:19:49 +02:00
|
|
|
#include "settings.h"
|
1999-11-04 22:56:02 +01:00
|
|
|
|
2017-09-06 00:17:47 +02:00
|
|
|
static bool DescribeQuery(const char *query, double *elapsed_msec);
|
2006-08-30 00:25:08 +02:00
|
|
|
static bool ExecQueryUsingCursor(const char *query, double *elapsed_msec);
|
2022-10-03 21:07:10 +02:00
|
|
|
static int ExecQueryAndProcessResults(const char *query,
|
|
|
|
double *elapsed_msec,
|
|
|
|
bool *svpt_gone_p,
|
|
|
|
bool is_watch,
|
|
|
|
const printQueryOpt *opt,
|
|
|
|
FILE *printQueryFout);
|
2004-09-20 20:51:19 +02:00
|
|
|
static bool command_no_begin(const char *query);
|
2006-08-30 00:25:08 +02:00
|
|
|
static bool is_select_command(const char *query);
|
2003-06-28 02:12:40 +02:00
|
|
|
|
2015-12-03 20:28:58 +01:00
|
|
|
|
1999-11-04 22:56:02 +01:00
|
|
|
/*
|
2015-12-03 20:28:58 +01:00
|
|
|
* openQueryOutputFile --- attempt to open a query output file
|
1999-11-04 22:56:02 +01:00
|
|
|
*
|
2015-12-03 20:28:58 +01:00
|
|
|
* fname == NULL selects stdout, else an initial '|' selects a pipe,
|
|
|
|
* else plain file.
|
|
|
|
*
|
|
|
|
* Returns output file pointer into *fout, and is-a-pipe flag into *is_pipe.
|
|
|
|
* Caller is responsible for adjusting SIGPIPE state if it's a pipe.
|
|
|
|
*
|
2017-08-16 06:22:32 +02:00
|
|
|
* On error, reports suitable error message and returns false.
|
1999-11-04 22:56:02 +01:00
|
|
|
*/
|
|
|
|
bool
|
2015-12-03 20:28:58 +01:00
|
|
|
openQueryOutputFile(const char *fname, FILE **fout, bool *is_pipe)
|
1999-11-04 22:56:02 +01:00
|
|
|
{
|
1999-11-05 00:14:30 +01:00
|
|
|
if (!fname || fname[0] == '\0')
|
|
|
|
{
|
2015-12-03 20:28:58 +01:00
|
|
|
*fout = stdout;
|
|
|
|
*is_pipe = false;
|
1999-11-05 00:14:30 +01:00
|
|
|
}
|
|
|
|
else if (*fname == '|')
|
|
|
|
{
|
2022-08-29 19:55:38 +02:00
|
|
|
fflush(NULL);
|
2015-12-03 20:28:58 +01:00
|
|
|
*fout = popen(fname + 1, "w");
|
|
|
|
*is_pipe = true;
|
1999-11-05 00:14:30 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2015-12-03 20:28:58 +01:00
|
|
|
*fout = fopen(fname, "w");
|
|
|
|
*is_pipe = false;
|
1999-11-05 00:14:30 +01:00
|
|
|
}
|
|
|
|
|
2015-12-03 20:28:58 +01:00
|
|
|
if (*fout == NULL)
|
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_error("%s: %m", fname);
|
2015-12-03 20:28:58 +01:00
|
|
|
return false;
|
1999-11-05 00:14:30 +01:00
|
|
|
}
|
|
|
|
|
2015-12-03 20:28:58 +01:00
|
|
|
return true;
|
1999-11-04 22:56:02 +01:00
|
|
|
}
|
|
|
|
|
2015-12-03 20:28:58 +01:00
|
|
|
/*
|
|
|
|
* setQFout
|
|
|
|
* -- handler for -o command line option and \o command
|
|
|
|
*
|
|
|
|
* On success, updates pset with the new output file and returns true.
|
|
|
|
* On failure, returns false without changing pset state.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
setQFout(const char *fname)
|
|
|
|
{
|
|
|
|
FILE *fout;
|
|
|
|
bool is_pipe;
|
|
|
|
|
|
|
|
/* First make sure we can open the new output file/pipe */
|
|
|
|
if (!openQueryOutputFile(fname, &fout, &is_pipe))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Close old file/pipe */
|
|
|
|
if (pset.queryFout && pset.queryFout != stdout && pset.queryFout != stderr)
|
|
|
|
{
|
|
|
|
if (pset.queryFoutPipe)
|
2023-04-06 23:33:38 +02:00
|
|
|
SetShellResultVariables(pclose(pset.queryFout));
|
2015-12-03 20:28:58 +01:00
|
|
|
else
|
|
|
|
fclose(pset.queryFout);
|
|
|
|
}
|
|
|
|
|
|
|
|
pset.queryFout = fout;
|
|
|
|
pset.queryFoutPipe = is_pipe;
|
|
|
|
|
|
|
|
/* Adjust SIGPIPE handling appropriately: ignore signal if is_pipe */
|
|
|
|
set_sigpipe_trap_state(is_pipe);
|
|
|
|
restore_sigpipe_trap();
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
1999-11-04 22:56:02 +01:00
|
|
|
|
|
|
|
|
2016-03-18 20:05:49 +01:00
|
|
|
/*
|
|
|
|
* Variable-fetching callback for flex lexer
|
|
|
|
*
|
|
|
|
* If the specified variable exists, return its value as a string (malloc'd
|
|
|
|
* and expected to be freed by the caller); else return NULL.
|
|
|
|
*
|
Allow psql variable substitution to occur in backtick command strings.
Previously, text between backquotes in a psql metacommand's arguments
was always passed to the shell literally. That considerably hobbles
the usefulness of the feature for scripting, so we'd foreseen for a long
time that we'd someday want to allow substitution of psql variables into
the shell command. IMO the addition of \if metacommands has brought us to
that point, since \if can greatly benefit from some sort of client-side
expression evaluation capability, and psql itself is not going to grow any
such thing in time for v10. Hence, this patch. It allows :VARIABLE to be
replaced by the exact contents of the named variable, while :'VARIABLE'
is replaced by the variable's contents suitably quoted to become a single
shell-command argument. (The quoting rules for that are different from
those for SQL literals, so this is a bit of an abuse of the :'VARIABLE'
notation, but I doubt anyone will be confused.)
As with other situations in psql, no substitution occurs if the word
following a colon is not a known variable name. That limits the risk of
compatibility problems for existing psql scripts; but the risk isn't zero,
so this needs to be called out in the v10 release notes.
Discussion: https://postgr.es/m/9561.1490895211@sss.pgh.pa.us
2017-04-02 03:44:54 +02:00
|
|
|
* If "quote" isn't PQUOTE_PLAIN, then return the value suitably quoted and
|
|
|
|
* escaped for the specified quoting requirement. (Failure in escaping
|
|
|
|
* should lead to printing an error and returning NULL.)
|
2017-03-13 22:14:46 +01:00
|
|
|
*
|
|
|
|
* "passthrough" is the pointer previously given to psql_scan_set_passthrough.
|
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
|
|
|
* In psql, passthrough points to a ConditionalStack, which we check to
|
|
|
|
* determine whether variable expansion is allowed.
|
2016-03-18 20:05:49 +01:00
|
|
|
*/
|
|
|
|
char *
|
Allow psql variable substitution to occur in backtick command strings.
Previously, text between backquotes in a psql metacommand's arguments
was always passed to the shell literally. That considerably hobbles
the usefulness of the feature for scripting, so we'd foreseen for a long
time that we'd someday want to allow substitution of psql variables into
the shell command. IMO the addition of \if metacommands has brought us to
that point, since \if can greatly benefit from some sort of client-side
expression evaluation capability, and psql itself is not going to grow any
such thing in time for v10. Hence, this patch. It allows :VARIABLE to be
replaced by the exact contents of the named variable, while :'VARIABLE'
is replaced by the variable's contents suitably quoted to become a single
shell-command argument. (The quoting rules for that are different from
those for SQL literals, so this is a bit of an abuse of the :'VARIABLE'
notation, but I doubt anyone will be confused.)
As with other situations in psql, no substitution occurs if the word
following a colon is not a known variable name. That limits the risk of
compatibility problems for existing psql scripts; but the risk isn't zero,
so this needs to be called out in the v10 release notes.
Discussion: https://postgr.es/m/9561.1490895211@sss.pgh.pa.us
2017-04-02 03:44:54 +02:00
|
|
|
psql_get_variable(const char *varname, PsqlScanQuoteType quote,
|
2017-03-13 22:14:46 +01:00
|
|
|
void *passthrough)
|
2016-03-18 20:05:49 +01:00
|
|
|
{
|
Allow psql variable substitution to occur in backtick command strings.
Previously, text between backquotes in a psql metacommand's arguments
was always passed to the shell literally. That considerably hobbles
the usefulness of the feature for scripting, so we'd foreseen for a long
time that we'd someday want to allow substitution of psql variables into
the shell command. IMO the addition of \if metacommands has brought us to
that point, since \if can greatly benefit from some sort of client-side
expression evaluation capability, and psql itself is not going to grow any
such thing in time for v10. Hence, this patch. It allows :VARIABLE to be
replaced by the exact contents of the named variable, while :'VARIABLE'
is replaced by the variable's contents suitably quoted to become a single
shell-command argument. (The quoting rules for that are different from
those for SQL literals, so this is a bit of an abuse of the :'VARIABLE'
notation, but I doubt anyone will be confused.)
As with other situations in psql, no substitution occurs if the word
following a colon is not a known variable name. That limits the risk of
compatibility problems for existing psql scripts; but the risk isn't zero,
so this needs to be called out in the v10 release notes.
Discussion: https://postgr.es/m/9561.1490895211@sss.pgh.pa.us
2017-04-02 03:44:54 +02:00
|
|
|
char *result = NULL;
|
2016-03-18 20:05:49 +01:00
|
|
|
const char *value;
|
|
|
|
|
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
|
|
|
/* In an inactive \if branch, suppress all variable substitutions */
|
|
|
|
if (passthrough && !conditional_active((ConditionalStack) passthrough))
|
|
|
|
return NULL;
|
|
|
|
|
2016-03-18 20:05:49 +01:00
|
|
|
value = GetVariable(pset.vars, varname);
|
|
|
|
if (!value)
|
|
|
|
return NULL;
|
|
|
|
|
Allow psql variable substitution to occur in backtick command strings.
Previously, text between backquotes in a psql metacommand's arguments
was always passed to the shell literally. That considerably hobbles
the usefulness of the feature for scripting, so we'd foreseen for a long
time that we'd someday want to allow substitution of psql variables into
the shell command. IMO the addition of \if metacommands has brought us to
that point, since \if can greatly benefit from some sort of client-side
expression evaluation capability, and psql itself is not going to grow any
such thing in time for v10. Hence, this patch. It allows :VARIABLE to be
replaced by the exact contents of the named variable, while :'VARIABLE'
is replaced by the variable's contents suitably quoted to become a single
shell-command argument. (The quoting rules for that are different from
those for SQL literals, so this is a bit of an abuse of the :'VARIABLE'
notation, but I doubt anyone will be confused.)
As with other situations in psql, no substitution occurs if the word
following a colon is not a known variable name. That limits the risk of
compatibility problems for existing psql scripts; but the risk isn't zero,
so this needs to be called out in the v10 release notes.
Discussion: https://postgr.es/m/9561.1490895211@sss.pgh.pa.us
2017-04-02 03:44:54 +02:00
|
|
|
switch (quote)
|
2016-03-18 20:05:49 +01:00
|
|
|
{
|
Allow psql variable substitution to occur in backtick command strings.
Previously, text between backquotes in a psql metacommand's arguments
was always passed to the shell literally. That considerably hobbles
the usefulness of the feature for scripting, so we'd foreseen for a long
time that we'd someday want to allow substitution of psql variables into
the shell command. IMO the addition of \if metacommands has brought us to
that point, since \if can greatly benefit from some sort of client-side
expression evaluation capability, and psql itself is not going to grow any
such thing in time for v10. Hence, this patch. It allows :VARIABLE to be
replaced by the exact contents of the named variable, while :'VARIABLE'
is replaced by the variable's contents suitably quoted to become a single
shell-command argument. (The quoting rules for that are different from
those for SQL literals, so this is a bit of an abuse of the :'VARIABLE'
notation, but I doubt anyone will be confused.)
As with other situations in psql, no substitution occurs if the word
following a colon is not a known variable name. That limits the risk of
compatibility problems for existing psql scripts; but the risk isn't zero,
so this needs to be called out in the v10 release notes.
Discussion: https://postgr.es/m/9561.1490895211@sss.pgh.pa.us
2017-04-02 03:44:54 +02:00
|
|
|
case PQUOTE_PLAIN:
|
|
|
|
result = pg_strdup(value);
|
|
|
|
break;
|
|
|
|
case PQUOTE_SQL_LITERAL:
|
|
|
|
case PQUOTE_SQL_IDENT:
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* For these cases, we use libpq's quoting functions, which
|
|
|
|
* assume the string is in the connection's client encoding.
|
|
|
|
*/
|
|
|
|
char *escaped_value;
|
|
|
|
|
|
|
|
if (!pset.db)
|
|
|
|
{
|
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_error("cannot escape without active connection");
|
Allow psql variable substitution to occur in backtick command strings.
Previously, text between backquotes in a psql metacommand's arguments
was always passed to the shell literally. That considerably hobbles
the usefulness of the feature for scripting, so we'd foreseen for a long
time that we'd someday want to allow substitution of psql variables into
the shell command. IMO the addition of \if metacommands has brought us to
that point, since \if can greatly benefit from some sort of client-side
expression evaluation capability, and psql itself is not going to grow any
such thing in time for v10. Hence, this patch. It allows :VARIABLE to be
replaced by the exact contents of the named variable, while :'VARIABLE'
is replaced by the variable's contents suitably quoted to become a single
shell-command argument. (The quoting rules for that are different from
those for SQL literals, so this is a bit of an abuse of the :'VARIABLE'
notation, but I doubt anyone will be confused.)
As with other situations in psql, no substitution occurs if the word
following a colon is not a known variable name. That limits the risk of
compatibility problems for existing psql scripts; but the risk isn't zero,
so this needs to be called out in the v10 release notes.
Discussion: https://postgr.es/m/9561.1490895211@sss.pgh.pa.us
2017-04-02 03:44:54 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (quote == PQUOTE_SQL_LITERAL)
|
|
|
|
escaped_value =
|
|
|
|
PQescapeLiteral(pset.db, value, strlen(value));
|
|
|
|
else
|
|
|
|
escaped_value =
|
|
|
|
PQescapeIdentifier(pset.db, value, strlen(value));
|
|
|
|
|
|
|
|
if (escaped_value == NULL)
|
|
|
|
{
|
|
|
|
const char *error = PQerrorMessage(pset.db);
|
|
|
|
|
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_info("%s", error);
|
Allow psql variable substitution to occur in backtick command strings.
Previously, text between backquotes in a psql metacommand's arguments
was always passed to the shell literally. That considerably hobbles
the usefulness of the feature for scripting, so we'd foreseen for a long
time that we'd someday want to allow substitution of psql variables into
the shell command. IMO the addition of \if metacommands has brought us to
that point, since \if can greatly benefit from some sort of client-side
expression evaluation capability, and psql itself is not going to grow any
such thing in time for v10. Hence, this patch. It allows :VARIABLE to be
replaced by the exact contents of the named variable, while :'VARIABLE'
is replaced by the variable's contents suitably quoted to become a single
shell-command argument. (The quoting rules for that are different from
those for SQL literals, so this is a bit of an abuse of the :'VARIABLE'
notation, but I doubt anyone will be confused.)
As with other situations in psql, no substitution occurs if the word
following a colon is not a known variable name. That limits the risk of
compatibility problems for existing psql scripts; but the risk isn't zero,
so this needs to be called out in the v10 release notes.
Discussion: https://postgr.es/m/9561.1490895211@sss.pgh.pa.us
2017-04-02 03:44:54 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Rather than complicate the lexer's API with a notion of
|
|
|
|
* which free() routine to use, just pay the price of an extra
|
|
|
|
* strdup().
|
|
|
|
*/
|
|
|
|
result = pg_strdup(escaped_value);
|
|
|
|
PQfreemem(escaped_value);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case PQUOTE_SHELL_ARG:
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* For this we use appendShellStringNoError, which is
|
|
|
|
* encoding-agnostic, which is fine since the shell probably
|
|
|
|
* is too. In any case, the only special character is "'",
|
|
|
|
* which is not known to appear in valid multibyte characters.
|
|
|
|
*/
|
|
|
|
PQExpBufferData buf;
|
|
|
|
|
|
|
|
initPQExpBuffer(&buf);
|
|
|
|
if (!appendShellStringNoError(&buf, value))
|
|
|
|
{
|
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_error("shell command argument contains a newline or carriage return: \"%s\"",
|
Allow psql variable substitution to occur in backtick command strings.
Previously, text between backquotes in a psql metacommand's arguments
was always passed to the shell literally. That considerably hobbles
the usefulness of the feature for scripting, so we'd foreseen for a long
time that we'd someday want to allow substitution of psql variables into
the shell command. IMO the addition of \if metacommands has brought us to
that point, since \if can greatly benefit from some sort of client-side
expression evaluation capability, and psql itself is not going to grow any
such thing in time for v10. Hence, this patch. It allows :VARIABLE to be
replaced by the exact contents of the named variable, while :'VARIABLE'
is replaced by the variable's contents suitably quoted to become a single
shell-command argument. (The quoting rules for that are different from
those for SQL literals, so this is a bit of an abuse of the :'VARIABLE'
notation, but I doubt anyone will be confused.)
As with other situations in psql, no substitution occurs if the word
following a colon is not a known variable name. That limits the risk of
compatibility problems for existing psql scripts; but the risk isn't zero,
so this needs to be called out in the v10 release notes.
Discussion: https://postgr.es/m/9561.1490895211@sss.pgh.pa.us
2017-04-02 03:44:54 +02:00
|
|
|
value);
|
|
|
|
free(buf.data);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
result = buf.data;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* No default: we want a compiler warning for missing cases */
|
2016-03-18 20:05:49 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-02-08 00:10:11 +01:00
|
|
|
/*
|
2003-03-10 23:28:22 +01:00
|
|
|
* for backend Notice messages (INFO, WARNING, etc)
|
2000-02-08 00:10:11 +01:00
|
|
|
*/
|
2000-01-19 00:30:24 +01:00
|
|
|
void
|
|
|
|
NoticeProcessor(void *arg, const char *message)
|
|
|
|
{
|
|
|
|
(void) arg; /* not used */
|
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_info("%s", message);
|
2000-01-19 00:30:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
1999-11-04 22:56:02 +01:00
|
|
|
/*
|
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
|
|
|
* Code to support query cancellation
|
1999-11-04 22:56:02 +01:00
|
|
|
*
|
2006-06-14 18:49:03 +02:00
|
|
|
* Before we start a query, we enable the SIGINT signal catcher to send a
|
2019-12-02 03:18:56 +01:00
|
|
|
* cancel request to the backend.
|
2006-06-14 18:49:03 +02:00
|
|
|
*
|
|
|
|
* SIGINT is supposed to abort all long-running psql operations, not only
|
|
|
|
* database queries. In most places, this is accomplished by checking
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
* cancel_pressed during long-running loops. However, that won't work when
|
2006-06-14 18:49:03 +02:00
|
|
|
* blocked on user input (in readline() or fgets()). In those places, we
|
2017-08-16 06:22:32 +02:00
|
|
|
* set sigint_interrupt_enabled true while blocked, instructing the signal
|
2006-06-14 18:49:03 +02:00
|
|
|
* catcher to longjmp through sigint_interrupt_jmp. We assume readline and
|
2019-12-02 03:18:56 +01:00
|
|
|
* fgets are coded to handle possible interruption.
|
|
|
|
*
|
|
|
|
* On Windows, currently this does not work, so control-C is less useful
|
Rethink definition of cancel.c's CancelRequested flag.
As it stands, this flag is only set when we've successfully sent a
cancel request, not if we get SIGINT and then fail to send a cancel.
However, for almost all callers, that's the Wrong Thing: we'd prefer
to abort processing after control-C even if no cancel could be sent.
As an example, since commit 1d468b9ad "pgbench -i" fails to give up
sending COPY data even after control-C, if the postmaster has been
stopped, which is clearly not what the code intends and not what anyone
would want. (The fact that it keeps going at all is the fault of a
separate bug in libpq, but not letting CancelRequested become set is
clearly not what we want here.)
The sole exception, as far as I can find, is that scripts_parallel.c's
ParallelSlotsGetIdle tries to consume a query result after issuing a
cancel, which of course might not terminate quickly if no cancel
happened. But that behavior was poorly thought out too. No user of
ParallelSlotsGetIdle tries to continue processing after a cancel,
so there is really no point in trying to clear the connection's state.
Moreover this has the same defect as for other users of cancel.c,
that if the cancel request fails for some reason then we end up with
control-C being completely ignored. (On top of that, select_loop failed
to distinguish clearly between SIGINT and other reasons for select(2)
failing, which means that it's possible that the existing code would
think that a cancel has been sent when it hasn't.)
Hence, redefine CancelRequested as simply meaning that SIGINT was
received. We could add a second flag with the other meaning, but
in the absence of any compelling argument why such a flag is needed,
I think it would just offer an opportunity for future callers to
get it wrong. Also remove the consumeQueryResult call in
ParallelSlotsGetIdle's failure exit. In passing, simplify the
API of select_loop.
It would now be possible to re-unify psql's cancel_pressed with
CancelRequested, partly undoing 5d43c3c54. But I'm not really
convinced that that's worth the trouble, so I left psql alone,
other than fixing a misleading comment.
This code is new in v13 (cf a4fd3aa71), so no need for back-patch.
Per investigation of a complaint from Andres Freund.
Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de
2020-06-07 19:07:31 +02:00
|
|
|
* there.
|
1999-11-04 22:56:02 +01:00
|
|
|
*/
|
2022-09-29 07:28:13 +02:00
|
|
|
volatile sig_atomic_t sigint_interrupt_enabled = false;
|
2006-06-14 18:49:03 +02:00
|
|
|
|
|
|
|
sigjmp_buf sigint_interrupt_jmp;
|
|
|
|
|
|
|
|
static void
|
2019-12-02 03:18:56 +01:00
|
|
|
psql_cancel_callback(void)
|
1999-11-04 22:56:02 +01:00
|
|
|
{
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
#ifndef WIN32
|
2006-06-14 18:49:03 +02:00
|
|
|
/* if we are waiting for input, longjmp out of it */
|
|
|
|
if (sigint_interrupt_enabled)
|
|
|
|
{
|
|
|
|
sigint_interrupt_enabled = false;
|
|
|
|
siglongjmp(sigint_interrupt_jmp, 1);
|
|
|
|
}
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
#endif
|
2000-02-20 15:28:28 +01:00
|
|
|
|
2006-06-14 18:49:03 +02:00
|
|
|
/* else, set cancel flag to stop any long-running loops */
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
cancel_pressed = true;
|
2004-10-31 01:11:27 +02:00
|
|
|
}
|
|
|
|
|
2004-11-01 20:21:50 +01:00
|
|
|
void
|
2019-12-02 03:18:56 +01:00
|
|
|
psql_setup_cancel_handler(void)
|
2004-11-01 20:21:50 +01:00
|
|
|
{
|
2019-12-02 03:18:56 +01:00
|
|
|
setup_cancel_handler(psql_cancel_callback);
|
2004-10-31 01:11:27 +02:00
|
|
|
}
|
1999-11-04 22:56:02 +01:00
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
|
|
|
|
/* ConnectionUp
|
|
|
|
*
|
|
|
|
* Returns whether our backend connection is still there.
|
|
|
|
*/
|
|
|
|
static bool
|
2004-10-11 01:37:45 +02:00
|
|
|
ConnectionUp(void)
|
2003-03-20 07:00:12 +01:00
|
|
|
{
|
|
|
|
return PQstatus(pset.db) != CONNECTION_BAD;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* CheckConnection
|
|
|
|
*
|
|
|
|
* Verify that we still have a good connection to the backend, and if not,
|
|
|
|
* see if it can be restored.
|
|
|
|
*
|
|
|
|
* Returns true if either the connection was still there, or it could be
|
|
|
|
* restored successfully; false otherwise. If, however, there was no
|
|
|
|
* connection and the session is non-interactive, this will exit the program
|
|
|
|
* with a code of EXIT_BADCONN.
|
|
|
|
*/
|
|
|
|
static bool
|
2003-08-04 21:10:40 +02:00
|
|
|
CheckConnection(void)
|
2003-03-20 07:00:12 +01:00
|
|
|
{
|
|
|
|
bool OK;
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
OK = ConnectionUp();
|
|
|
|
if (!OK)
|
|
|
|
{
|
|
|
|
if (!pset.cur_cmd_interactive)
|
|
|
|
{
|
2022-04-08 20:55:14 +02:00
|
|
|
pg_log_error("connection to server was lost");
|
2003-03-20 07:00:12 +01:00
|
|
|
exit(EXIT_BADCONN);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
fprintf(stderr, _("The connection to the server was lost. Attempting reset: "));
|
2003-03-20 07:00:12 +01:00
|
|
|
PQreset(pset.db);
|
|
|
|
OK = ConnectionUp();
|
|
|
|
if (!OK)
|
|
|
|
{
|
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
|
|
|
fprintf(stderr, _("Failed.\n"));
|
Handle corner cases correctly in psql's reconnection logic.
After an unexpected connection loss and successful reconnection,
psql neglected to resynchronize its internal state about the server,
such as server version. Ordinarily we'd be reconnecting to the same
server and so this isn't really necessary, but there are scenarios
where we do need to update --- one example is where we have a list
of possible connection targets and they're not all alike.
Define "resynchronize" as including connection_warnings(), so that
this case acts the same as \connect. This seems useful; for example,
if the server version did change, the user might wish to know that.
An attuned user might also notice that the new connection isn't
SSL-encrypted, for example, though this approach isn't especially
in-your-face about such changes. Although this part is a behavioral
change, it only affects interactive sessions, so it should not break
any applications.
Also, in do_connect, make sure that we desynchronize correctly when
abandoning an old connection in non-interactive mode.
These problems evidently are the result of people patching only one
of the two places where psql deals with connection changes, so insert
some cross-referencing comments in hopes of forestalling future bugs
of the same ilk.
Lastly, in Windows builds, issue codepage mismatch warnings only at
startup, not during reconnections. psql's codepage can't change
during a reconnect, so complaining about it again seems like useless
noise.
Peter Billen and Tom Lane. Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com
2019-09-02 20:02:45 +02:00
|
|
|
|
|
|
|
/*
|
2020-10-23 23:07:15 +02:00
|
|
|
* Transition to having no connection; but stash away the failed
|
|
|
|
* connection so that we can still refer to its parameters in a
|
|
|
|
* later \connect attempt. Keep the state cleanup here in sync
|
|
|
|
* with do_connect().
|
Handle corner cases correctly in psql's reconnection logic.
After an unexpected connection loss and successful reconnection,
psql neglected to resynchronize its internal state about the server,
such as server version. Ordinarily we'd be reconnecting to the same
server and so this isn't really necessary, but there are scenarios
where we do need to update --- one example is where we have a list
of possible connection targets and they're not all alike.
Define "resynchronize" as including connection_warnings(), so that
this case acts the same as \connect. This seems useful; for example,
if the server version did change, the user might wish to know that.
An attuned user might also notice that the new connection isn't
SSL-encrypted, for example, though this approach isn't especially
in-your-face about such changes. Although this part is a behavioral
change, it only affects interactive sessions, so it should not break
any applications.
Also, in do_connect, make sure that we desynchronize correctly when
abandoning an old connection in non-interactive mode.
These problems evidently are the result of people patching only one
of the two places where psql deals with connection changes, so insert
some cross-referencing comments in hopes of forestalling future bugs
of the same ilk.
Lastly, in Windows builds, issue codepage mismatch warnings only at
startup, not during reconnections. psql's codepage can't change
during a reconnect, so complaining about it again seems like useless
noise.
Peter Billen and Tom Lane. Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com
2019-09-02 20:02:45 +02:00
|
|
|
*/
|
2020-10-23 23:07:15 +02:00
|
|
|
if (pset.dead_conn)
|
|
|
|
PQfinish(pset.dead_conn);
|
|
|
|
pset.dead_conn = pset.db;
|
2003-03-20 07:00:12 +01:00
|
|
|
pset.db = NULL;
|
|
|
|
ResetCancelConn();
|
2003-06-28 02:12:40 +02:00
|
|
|
UnsyncVariables();
|
2003-03-20 07:00:12 +01:00
|
|
|
}
|
|
|
|
else
|
Handle corner cases correctly in psql's reconnection logic.
After an unexpected connection loss and successful reconnection,
psql neglected to resynchronize its internal state about the server,
such as server version. Ordinarily we'd be reconnecting to the same
server and so this isn't really necessary, but there are scenarios
where we do need to update --- one example is where we have a list
of possible connection targets and they're not all alike.
Define "resynchronize" as including connection_warnings(), so that
this case acts the same as \connect. This seems useful; for example,
if the server version did change, the user might wish to know that.
An attuned user might also notice that the new connection isn't
SSL-encrypted, for example, though this approach isn't especially
in-your-face about such changes. Although this part is a behavioral
change, it only affects interactive sessions, so it should not break
any applications.
Also, in do_connect, make sure that we desynchronize correctly when
abandoning an old connection in non-interactive mode.
These problems evidently are the result of people patching only one
of the two places where psql deals with connection changes, so insert
some cross-referencing comments in hopes of forestalling future bugs
of the same ilk.
Lastly, in Windows builds, issue codepage mismatch warnings only at
startup, not during reconnections. psql's codepage can't change
during a reconnect, so complaining about it again seems like useless
noise.
Peter Billen and Tom Lane. Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com
2019-09-02 20:02:45 +02: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
|
|
|
fprintf(stderr, _("Succeeded.\n"));
|
Handle corner cases correctly in psql's reconnection logic.
After an unexpected connection loss and successful reconnection,
psql neglected to resynchronize its internal state about the server,
such as server version. Ordinarily we'd be reconnecting to the same
server and so this isn't really necessary, but there are scenarios
where we do need to update --- one example is where we have a list
of possible connection targets and they're not all alike.
Define "resynchronize" as including connection_warnings(), so that
this case acts the same as \connect. This seems useful; for example,
if the server version did change, the user might wish to know that.
An attuned user might also notice that the new connection isn't
SSL-encrypted, for example, though this approach isn't especially
in-your-face about such changes. Although this part is a behavioral
change, it only affects interactive sessions, so it should not break
any applications.
Also, in do_connect, make sure that we desynchronize correctly when
abandoning an old connection in non-interactive mode.
These problems evidently are the result of people patching only one
of the two places where psql deals with connection changes, so insert
some cross-referencing comments in hopes of forestalling future bugs
of the same ilk.
Lastly, in Windows builds, issue codepage mismatch warnings only at
startup, not during reconnections. psql's codepage can't change
during a reconnect, so complaining about it again seems like useless
noise.
Peter Billen and Tom Lane. Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com
2019-09-02 20:02:45 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Re-sync, just in case anything changed. Keep this in sync with
|
|
|
|
* do_connect().
|
|
|
|
*/
|
|
|
|
SyncVariables();
|
|
|
|
connection_warnings(false); /* Must be after SyncVariables */
|
|
|
|
}
|
2003-03-20 07:00:12 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* AcceptResult
|
|
|
|
*
|
|
|
|
* Checks whether a result is valid, giving an error message if necessary;
|
2006-08-30 00:25:08 +02:00
|
|
|
* and ensures that the connection to the backend is still up.
|
2003-03-20 07:00:12 +01:00
|
|
|
*
|
|
|
|
* Returns true for valid result, false for error state.
|
|
|
|
*/
|
|
|
|
static bool
|
2022-04-04 14:57:17 +02:00
|
|
|
AcceptResult(const PGresult *result, bool show_error)
|
2003-03-20 07:00:12 +01:00
|
|
|
{
|
2012-01-25 22:06:00 +01:00
|
|
|
bool OK;
|
2003-03-20 07:00:12 +01:00
|
|
|
|
|
|
|
if (!result)
|
|
|
|
OK = false;
|
|
|
|
else
|
|
|
|
switch (PQresultStatus(result))
|
|
|
|
{
|
|
|
|
case PGRES_COMMAND_OK:
|
|
|
|
case PGRES_TUPLES_OK:
|
2003-11-12 23:53:16 +01:00
|
|
|
case PGRES_EMPTY_QUERY:
|
2003-06-28 02:12:40 +02:00
|
|
|
case PGRES_COPY_IN:
|
2003-03-20 07:00:12 +01:00
|
|
|
case PGRES_COPY_OUT:
|
2006-06-14 18:49:03 +02:00
|
|
|
/* Fine, do nothing */
|
2012-01-25 22:06:00 +01:00
|
|
|
OK = true;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PGRES_BAD_RESPONSE:
|
|
|
|
case PGRES_NONFATAL_ERROR:
|
|
|
|
case PGRES_FATAL_ERROR:
|
|
|
|
OK = false;
|
2003-03-20 07:00:12 +01:00
|
|
|
break;
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
default:
|
|
|
|
OK = false;
|
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_error("unexpected PQresultStatus: %d",
|
2012-01-25 22:06:00 +01:00
|
|
|
PQresultStatus(result));
|
2003-03-20 07:00:12 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
if (!OK && show_error)
|
2003-03-20 07:00:12 +01:00
|
|
|
{
|
2005-10-13 22:58:42 +02:00
|
|
|
const char *error = PQerrorMessage(pset.db);
|
2005-10-15 04:49:52 +02:00
|
|
|
|
2005-10-13 22:58:42 +02:00
|
|
|
if (strlen(error))
|
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_info("%s", error);
|
2005-10-13 22:58:42 +02:00
|
|
|
|
2003-08-04 21:10:40 +02:00
|
|
|
CheckConnection();
|
2003-03-20 07:00:12 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-09-13 01:27:48 +02:00
|
|
|
/*
|
|
|
|
* Set special variables from a query result
|
|
|
|
* - ERROR: true/false, whether an error occurred on this query
|
|
|
|
* - SQLSTATE: code of error, or "00000" if no error, or "" if unknown
|
|
|
|
* - ROW_COUNT: how many rows were returned or affected, or "0"
|
|
|
|
* - LAST_ERROR_SQLSTATE: same for last error
|
|
|
|
* - LAST_ERROR_MESSAGE: message of last error
|
|
|
|
*
|
|
|
|
* Note: current policy is to apply this only to the results of queries
|
|
|
|
* entered by the user, not queries generated by slash commands.
|
|
|
|
*/
|
|
|
|
static void
|
2022-02-10 12:03:35 +01:00
|
|
|
SetResultVariables(PGresult *result, bool success)
|
2017-09-13 01:27:48 +02:00
|
|
|
{
|
|
|
|
if (success)
|
|
|
|
{
|
2022-02-10 12:03:35 +01:00
|
|
|
const char *ntuples = PQcmdTuples(result);
|
2017-09-13 01:27:48 +02:00
|
|
|
|
|
|
|
SetVariable(pset.vars, "ERROR", "false");
|
|
|
|
SetVariable(pset.vars, "SQLSTATE", "00000");
|
|
|
|
SetVariable(pset.vars, "ROW_COUNT", *ntuples ? ntuples : "0");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2022-02-10 12:03:35 +01:00
|
|
|
const char *code = PQresultErrorField(result, PG_DIAG_SQLSTATE);
|
|
|
|
const char *mesg = PQresultErrorField(result, PG_DIAG_MESSAGE_PRIMARY);
|
2017-09-13 01:27:48 +02:00
|
|
|
|
|
|
|
SetVariable(pset.vars, "ERROR", "true");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there is no SQLSTATE code, use an empty string. This can happen
|
|
|
|
* for libpq-detected errors (e.g., lost connection, ENOMEM).
|
|
|
|
*/
|
|
|
|
if (code == NULL)
|
|
|
|
code = "";
|
|
|
|
SetVariable(pset.vars, "SQLSTATE", code);
|
|
|
|
SetVariable(pset.vars, "ROW_COUNT", "0");
|
|
|
|
SetVariable(pset.vars, "LAST_ERROR_SQLSTATE", code);
|
|
|
|
SetVariable(pset.vars, "LAST_ERROR_MESSAGE", mesg ? mesg : "");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2023-04-06 23:33:38 +02:00
|
|
|
/*
|
|
|
|
* Set special variables from a shell command result
|
|
|
|
* - SHELL_ERROR: true/false, whether command returned exit code 0
|
|
|
|
* - SHELL_EXIT_CODE: exit code according to shell conventions
|
|
|
|
*
|
|
|
|
* The argument is a wait status as returned by wait(2) or waitpid(2),
|
|
|
|
* which also applies to pclose(3) and system(3).
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
SetShellResultVariables(int wait_result)
|
|
|
|
{
|
|
|
|
char buf[32];
|
|
|
|
|
|
|
|
SetVariable(pset.vars, "SHELL_ERROR",
|
|
|
|
(wait_result == 0) ? "false" : "true");
|
|
|
|
snprintf(buf, sizeof(buf), "%d", wait_result_to_exit_code(wait_result));
|
|
|
|
SetVariable(pset.vars, "SHELL_EXIT_CODE", buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-04-03 18:29:55 +02:00
|
|
|
/*
|
|
|
|
* ClearOrSaveResult
|
|
|
|
*
|
|
|
|
* If the result represents an error, remember it for possible display by
|
|
|
|
* \errverbose. Otherwise, just PQclear() it.
|
2017-09-13 01:27:48 +02:00
|
|
|
*
|
|
|
|
* Note: current policy is to apply this to the results of all queries,
|
|
|
|
* including "back door" queries, for debugging's sake. It's OK to use
|
|
|
|
* PQclear() directly on results known to not be error results, however.
|
2016-04-03 18:29:55 +02:00
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ClearOrSaveResult(PGresult *result)
|
|
|
|
{
|
|
|
|
if (result)
|
|
|
|
{
|
|
|
|
switch (PQresultStatus(result))
|
|
|
|
{
|
|
|
|
case PGRES_NONFATAL_ERROR:
|
|
|
|
case PGRES_FATAL_ERROR:
|
2022-07-03 20:11:05 +02:00
|
|
|
PQclear(pset.last_error_result);
|
2016-04-03 18:29:55 +02:00
|
|
|
pset.last_error_result = result;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
PQclear(result);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
/*
|
|
|
|
* Consume all results
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ClearOrSaveAllResults(void)
|
|
|
|
{
|
|
|
|
PGresult *result;
|
|
|
|
|
|
|
|
while ((result = PQgetResult(pset.db)) != NULL)
|
|
|
|
ClearOrSaveResult(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-09-03 21:29:03 +02:00
|
|
|
/*
|
|
|
|
* Print microtiming output. Always print raw milliseconds; if the interval
|
|
|
|
* is >= 1 second, also break it down into days/hours/minutes/seconds.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
PrintTiming(double elapsed_msec)
|
|
|
|
{
|
|
|
|
double seconds;
|
|
|
|
double minutes;
|
|
|
|
double hours;
|
|
|
|
double days;
|
|
|
|
|
|
|
|
if (elapsed_msec < 1000.0)
|
|
|
|
{
|
|
|
|
/* This is the traditional (pre-v10) output format */
|
|
|
|
printf(_("Time: %.3f ms\n"), elapsed_msec);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: we could print just seconds, in a format like %06.3f, when the
|
|
|
|
* total is less than 1min. But that's hard to interpret unless we tack
|
|
|
|
* on "s" or otherwise annotate it. Forcing the display to include
|
|
|
|
* minutes seems like a better solution.
|
|
|
|
*/
|
|
|
|
seconds = elapsed_msec / 1000.0;
|
|
|
|
minutes = floor(seconds / 60.0);
|
|
|
|
seconds -= 60.0 * minutes;
|
|
|
|
if (minutes < 60.0)
|
|
|
|
{
|
|
|
|
printf(_("Time: %.3f ms (%02d:%06.3f)\n"),
|
|
|
|
elapsed_msec, (int) minutes, seconds);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
hours = floor(minutes / 60.0);
|
|
|
|
minutes -= 60.0 * hours;
|
|
|
|
if (hours < 24.0)
|
|
|
|
{
|
|
|
|
printf(_("Time: %.3f ms (%02d:%02d:%06.3f)\n"),
|
|
|
|
elapsed_msec, (int) hours, (int) minutes, seconds);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
days = floor(hours / 24.0);
|
|
|
|
hours -= 24.0 * days;
|
|
|
|
printf(_("Time: %.3f ms (%.0f d %02d:%02d:%06.3f)\n"),
|
|
|
|
elapsed_msec, days, (int) hours, (int) minutes, seconds);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1999-11-05 00:14:30 +01:00
|
|
|
/*
|
|
|
|
* PSQLexec
|
1999-11-04 22:56:02 +01:00
|
|
|
*
|
|
|
|
* This is the way to send "backdoor" queries (those not directly entered
|
2000-01-14 23:18:03 +01:00
|
|
|
* by the user). It is subject to -E but not -e.
|
2002-10-15 04:24:16 +02:00
|
|
|
*
|
2006-03-04 00:38:30 +01:00
|
|
|
* Caller is responsible for handling the ensuing processing if a COPY
|
|
|
|
* command is sent.
|
|
|
|
*
|
2003-09-16 19:59:02 +02:00
|
|
|
* Note: we don't bother to check PQclientEncoding; it is assumed that no
|
|
|
|
* caller uses this path to issue "SET CLIENT_ENCODING".
|
1999-11-04 22:56:02 +01:00
|
|
|
*/
|
1999-11-05 00:14:30 +01:00
|
|
|
PGresult *
|
2014-10-23 15:33:56 +02:00
|
|
|
PSQLexec(const char *query)
|
1999-11-04 22:56:02 +01:00
|
|
|
{
|
2003-06-28 02:12:40 +02:00
|
|
|
PGresult *res;
|
1999-11-05 00:14:30 +01:00
|
|
|
|
2000-01-14 23:18:03 +01:00
|
|
|
if (!pset.db)
|
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_error("You are currently not connected to a database.");
|
1999-11-05 00:14:30 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2006-08-29 17:19:51 +02:00
|
|
|
if (pset.echo_hidden != PSQL_ECHO_HIDDEN_OFF)
|
1999-11-05 00:14:30 +01:00
|
|
|
{
|
2005-10-04 21:01:18 +02:00
|
|
|
printf(_("********* QUERY **********\n"
|
|
|
|
"%s\n"
|
|
|
|
"**************************\n\n"), query);
|
1999-11-05 00:14:30 +01:00
|
|
|
fflush(stdout);
|
2005-06-14 04:57:45 +02:00
|
|
|
if (pset.logfile)
|
|
|
|
{
|
2005-10-04 21:01:18 +02:00
|
|
|
fprintf(pset.logfile,
|
|
|
|
_("********* QUERY **********\n"
|
|
|
|
"%s\n"
|
|
|
|
"**************************\n\n"), query);
|
2005-06-14 04:57:45 +02:00
|
|
|
fflush(pset.logfile);
|
|
|
|
}
|
1999-11-05 00:14:30 +01:00
|
|
|
|
2006-08-29 17:19:51 +02:00
|
|
|
if (pset.echo_hidden == PSQL_ECHO_HIDDEN_NOEXEC)
|
2003-06-28 02:12:40 +02:00
|
|
|
return NULL;
|
2003-03-20 07:43:35 +01:00
|
|
|
}
|
1999-11-05 00:14:30 +01:00
|
|
|
|
2019-12-02 03:18:56 +01:00
|
|
|
SetCancelConn(pset.db);
|
2003-03-20 07:00:12 +01:00
|
|
|
|
2003-06-28 02:12:40 +02:00
|
|
|
res = PQexec(pset.db, query);
|
|
|
|
|
2006-08-30 00:25:08 +02:00
|
|
|
ResetCancelConn();
|
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
if (!AcceptResult(res, true))
|
2003-02-19 04:54:39 +01:00
|
|
|
{
|
2016-04-03 18:29:55 +02:00
|
|
|
ClearOrSaveResult(res);
|
2003-03-20 07:00:12 +01:00
|
|
|
res = NULL;
|
2003-06-28 02:12:40 +02:00
|
|
|
}
|
2003-02-19 04:54:39 +01:00
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
return res;
|
1999-11-04 22:56:02 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-09-04 05:31:48 +02:00
|
|
|
/*
|
|
|
|
* PSQLexecWatch
|
|
|
|
*
|
|
|
|
* This function is used for \watch command to send the query to
|
2022-02-10 12:03:35 +01:00
|
|
|
* the server and print out the result.
|
2014-09-04 05:31:48 +02:00
|
|
|
*
|
|
|
|
* Returns 1 if the query executed successfully, 0 if it cannot be repeated,
|
|
|
|
* e.g., because of the interrupt, -1 on error.
|
|
|
|
*/
|
|
|
|
int
|
2021-07-13 01:13:48 +02:00
|
|
|
PSQLexecWatch(const char *query, const printQueryOpt *opt, FILE *printQueryFout)
|
2014-09-04 05:31:48 +02:00
|
|
|
{
|
2021-10-12 21:14:50 +02:00
|
|
|
bool timing = pset.timing;
|
2014-09-04 05:31:48 +02:00
|
|
|
double elapsed_msec = 0;
|
2022-04-04 14:57:17 +02:00
|
|
|
int res;
|
2014-09-04 05:31:48 +02:00
|
|
|
|
|
|
|
if (!pset.db)
|
|
|
|
{
|
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_error("You are currently not connected to a database.");
|
2014-09-04 05:31:48 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-02 03:18:56 +01:00
|
|
|
SetCancelConn(pset.db);
|
2021-04-15 19:41:42 +02:00
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
res = ExecQueryAndProcessResults(query, &elapsed_msec, NULL, true, opt, printQueryFout);
|
2021-04-15 19:41:42 +02:00
|
|
|
|
2014-09-04 05:31:48 +02:00
|
|
|
ResetCancelConn();
|
|
|
|
|
|
|
|
/* Possible microtiming output */
|
2021-10-12 21:14:50 +02:00
|
|
|
if (timing)
|
2016-09-03 21:29:03 +02:00
|
|
|
PrintTiming(elapsed_msec);
|
2014-09-04 05:31:48 +02:00
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
return res;
|
2014-09-04 05:31:48 +02:00
|
|
|
}
|
|
|
|
|
1999-11-04 22:56:02 +01:00
|
|
|
|
|
|
|
/*
|
2003-03-20 07:00:12 +01:00
|
|
|
* PrintNotifications: check for asynchronous notifications, and print them out
|
1999-11-04 22:56:02 +01:00
|
|
|
*/
|
2003-03-20 07:00:12 +01:00
|
|
|
static void
|
|
|
|
PrintNotifications(void)
|
1999-11-04 22:56:02 +01:00
|
|
|
{
|
2003-02-21 22:34:27 +01:00
|
|
|
PGnotify *notify;
|
1999-11-05 00:14:30 +01:00
|
|
|
|
2018-10-20 04:22:57 +02:00
|
|
|
PQconsumeInput(pset.db);
|
|
|
|
while ((notify = PQnotifies(pset.db)) != NULL)
|
2000-01-14 23:18:03 +01:00
|
|
|
{
|
2010-02-16 23:34:57 +01:00
|
|
|
/* for backward compatibility, only show payload if nonempty */
|
|
|
|
if (notify->extra[0])
|
|
|
|
fprintf(pset.queryFout, _("Asynchronous notification \"%s\" with payload \"%s\" received from server process with PID %d.\n"),
|
|
|
|
notify->relname, notify->extra, notify->be_pid);
|
|
|
|
else
|
|
|
|
fprintf(pset.queryFout, _("Asynchronous notification \"%s\" received from server process with PID %d.\n"),
|
|
|
|
notify->relname, notify->be_pid);
|
2003-03-20 07:00:12 +01:00
|
|
|
fflush(pset.queryFout);
|
2003-09-16 19:59:02 +02:00
|
|
|
PQfreemem(notify);
|
2018-10-20 04:22:57 +02:00
|
|
|
PQconsumeInput(pset.db);
|
2000-01-14 23:18:03 +01:00
|
|
|
}
|
2003-03-20 07:00:12 +01:00
|
|
|
}
|
1999-11-04 22:56:02 +01:00
|
|
|
|
1999-11-05 00:14:30 +01:00
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
/*
|
|
|
|
* PrintQueryTuples: assuming query result is OK, print its tuples
|
|
|
|
*
|
2022-10-03 21:07:10 +02:00
|
|
|
* We use the options given by opt unless that's NULL, in which case
|
|
|
|
* we use pset.popt.
|
|
|
|
*
|
|
|
|
* Output is to printQueryFout unless that's NULL, in which case
|
|
|
|
* we use pset.queryFout.
|
|
|
|
*
|
2003-03-20 07:00:12 +01:00
|
|
|
* Returns true if successful, false otherwise.
|
|
|
|
*/
|
|
|
|
static bool
|
2022-10-03 21:07:10 +02:00
|
|
|
PrintQueryTuples(const PGresult *result, const printQueryOpt *opt,
|
|
|
|
FILE *printQueryFout)
|
2003-03-20 07:00:12 +01:00
|
|
|
{
|
2022-02-10 12:03:35 +01:00
|
|
|
bool ok = true;
|
2022-10-03 21:07:10 +02:00
|
|
|
FILE *fout = printQueryFout ? printQueryFout : pset.queryFout;
|
2005-06-13 08:36:22 +02:00
|
|
|
|
2022-10-03 21:07:10 +02:00
|
|
|
printQuery(result, opt ? opt : &pset.popt, fout, false, pset.logfile);
|
|
|
|
fflush(fout);
|
|
|
|
if (ferror(fout))
|
2020-03-20 16:04:15 +01:00
|
|
|
{
|
2022-10-03 21:07:10 +02:00
|
|
|
pg_log_error("could not print result table: %m");
|
|
|
|
ok = false;
|
2020-03-20 16:04:15 +01:00
|
|
|
}
|
2003-03-20 07:00:12 +01:00
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
return ok;
|
2003-03-20 07:00:12 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-02-02 23:06:38 +01:00
|
|
|
/*
|
|
|
|
* StoreQueryTuple: assuming query result is OK, save data into variables
|
|
|
|
*
|
|
|
|
* Returns true if successful, false otherwise.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
StoreQueryTuple(const PGresult *result)
|
|
|
|
{
|
|
|
|
bool success = true;
|
|
|
|
|
|
|
|
if (PQntuples(result) < 1)
|
|
|
|
{
|
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_error("no rows returned for \\gset");
|
2013-02-02 23:06:38 +01:00
|
|
|
success = false;
|
|
|
|
}
|
|
|
|
else if (PQntuples(result) > 1)
|
|
|
|
{
|
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_error("more than one row returned for \\gset");
|
2013-02-02 23:06:38 +01:00
|
|
|
success = false;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < PQnfields(result); i++)
|
|
|
|
{
|
|
|
|
char *colname = PQfname(result, i);
|
|
|
|
char *varname;
|
|
|
|
char *value;
|
|
|
|
|
2017-02-06 10:33:58 +01:00
|
|
|
/* concatenate prefix and column name */
|
2013-10-23 01:40:26 +02:00
|
|
|
varname = psprintf("%s%s", pset.gset_prefix, colname);
|
2013-02-02 23:06:38 +01:00
|
|
|
|
2020-11-09 16:32:09 +01:00
|
|
|
if (VariableHasHook(pset.vars, varname))
|
|
|
|
{
|
|
|
|
pg_log_warning("attempt to \\gset into specially treated variable \"%s\" ignored",
|
|
|
|
varname);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2013-02-02 23:06:38 +01:00
|
|
|
if (!PQgetisnull(result, 0, i))
|
|
|
|
value = PQgetvalue(result, 0, i);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* for NULL value, unset rather than set the variable */
|
|
|
|
value = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!SetVariable(pset.vars, varname, value))
|
|
|
|
{
|
|
|
|
free(varname);
|
|
|
|
success = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
free(varname);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* ExecQueryTuples: assuming query result is OK, execute each query
|
|
|
|
* result field as a SQL statement
|
|
|
|
*
|
|
|
|
* Returns true if successful, false otherwise.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
ExecQueryTuples(const PGresult *result)
|
|
|
|
{
|
|
|
|
bool success = true;
|
|
|
|
int nrows = PQntuples(result);
|
|
|
|
int ncolumns = PQnfields(result);
|
|
|
|
int r,
|
|
|
|
c;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We must turn off gexec_flag to avoid infinite recursion. Note that
|
|
|
|
* this allows ExecQueryUsingCursor to be applied to the individual query
|
|
|
|
* results. SendQuery prevents it from being applied when fetching the
|
|
|
|
* queries-to-execute, because it can't handle recursion either.
|
|
|
|
*/
|
|
|
|
pset.gexec_flag = false;
|
|
|
|
|
|
|
|
for (r = 0; r < nrows; r++)
|
|
|
|
{
|
|
|
|
for (c = 0; c < ncolumns; c++)
|
|
|
|
{
|
|
|
|
if (!PQgetisnull(result, r, c))
|
|
|
|
{
|
|
|
|
const char *query = PQgetvalue(result, r, c);
|
|
|
|
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
/* Abandon execution if cancel_pressed */
|
|
|
|
if (cancel_pressed)
|
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
|
|
|
goto loop_exit;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ECHO_ALL mode should echo these queries, but SendQuery
|
|
|
|
* assumes that MainLoop did that, so we have to do it here.
|
|
|
|
*/
|
|
|
|
if (pset.echo == PSQL_ECHO_ALL && !pset.singlestep)
|
|
|
|
{
|
|
|
|
puts(query);
|
|
|
|
fflush(stdout);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!SendQuery(query))
|
|
|
|
{
|
|
|
|
/* Error - abandon execution if ON_ERROR_STOP */
|
|
|
|
success = false;
|
|
|
|
if (pset.on_error_stop)
|
|
|
|
goto loop_exit;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
loop_exit:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Restore state. We know gexec_flag was on, else we'd not be here. (We
|
|
|
|
* also know it'll get turned off at end of command, but that's not ours
|
|
|
|
* to do here.)
|
|
|
|
*/
|
|
|
|
pset.gexec_flag = true;
|
|
|
|
|
|
|
|
/* Return true if all queries were successful */
|
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2022-04-01 13:00:43 +02:00
|
|
|
/*
|
2022-10-03 21:07:10 +02:00
|
|
|
* Marshal the COPY data. Either path will get the
|
2022-04-01 13:00:43 +02:00
|
|
|
* connection out of its COPY state, then call PQresultStatus()
|
|
|
|
* once and report any error. Return whether all was ok.
|
|
|
|
*
|
2022-10-03 21:07:10 +02:00
|
|
|
* For COPY OUT, direct the output to copystream, or discard if that's NULL.
|
2022-04-01 13:00:43 +02:00
|
|
|
* For COPY IN, use pset.copyStream as data source if it's set,
|
|
|
|
* otherwise cur_cmd_source.
|
|
|
|
*
|
2022-10-03 21:07:10 +02:00
|
|
|
* Update *resultp if further processing is necessary; set to NULL otherwise.
|
2022-04-01 13:00:43 +02:00
|
|
|
* Return a result when queryFout can safely output a result status: on COPY
|
|
|
|
* IN, or on COPY OUT if written to something other than pset.queryFout.
|
|
|
|
* Returning NULL prevents the command status from being printed, which we
|
|
|
|
* want if the status line doesn't get taken as part of the COPY data.
|
|
|
|
*/
|
|
|
|
static bool
|
2022-10-03 21:07:10 +02:00
|
|
|
HandleCopyResult(PGresult **resultp, FILE *copystream)
|
2022-04-01 13:00:43 +02:00
|
|
|
{
|
|
|
|
bool success;
|
|
|
|
PGresult *copy_result;
|
|
|
|
ExecStatusType result_status = PQresultStatus(*resultp);
|
|
|
|
|
|
|
|
Assert(result_status == PGRES_COPY_OUT ||
|
|
|
|
result_status == PGRES_COPY_IN);
|
|
|
|
|
|
|
|
SetCancelConn(pset.db);
|
|
|
|
|
|
|
|
if (result_status == PGRES_COPY_OUT)
|
|
|
|
{
|
|
|
|
success = handleCopyOut(pset.db,
|
|
|
|
copystream,
|
|
|
|
©_result)
|
|
|
|
&& (copystream != NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Suppress status printing if the report would go to the same place
|
|
|
|
* as the COPY data just went. Note this doesn't prevent error
|
|
|
|
* reporting, since handleCopyOut did that.
|
|
|
|
*/
|
|
|
|
if (copystream == pset.queryFout)
|
|
|
|
{
|
|
|
|
PQclear(copy_result);
|
|
|
|
copy_result = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* COPY IN */
|
2022-10-03 21:07:10 +02:00
|
|
|
/* Ignore the copystream argument passed to the function */
|
2022-04-01 13:00:43 +02:00
|
|
|
copystream = pset.copyStream ? pset.copyStream : pset.cur_cmd_source;
|
|
|
|
success = handleCopyIn(pset.db,
|
|
|
|
copystream,
|
|
|
|
PQbinaryTuples(*resultp),
|
|
|
|
©_result);
|
|
|
|
}
|
|
|
|
ResetCancelConn();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Replace the PGRES_COPY_OUT/IN result with COPY command's exit status,
|
|
|
|
* or with NULL if we want to suppress printing anything.
|
|
|
|
*/
|
|
|
|
PQclear(*resultp);
|
|
|
|
*resultp = copy_result;
|
|
|
|
|
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
2006-08-13 23:10:04 +02:00
|
|
|
/*
|
|
|
|
* PrintQueryStatus: report command status as required
|
|
|
|
*
|
2022-02-10 12:03:35 +01:00
|
|
|
* Note: Utility function for use by PrintQueryResult() only.
|
2006-08-13 23:10:04 +02:00
|
|
|
*/
|
|
|
|
static void
|
2022-04-04 14:57:17 +02:00
|
|
|
PrintQueryStatus(PGresult *result, FILE *printQueryFout)
|
2006-08-13 23:10:04 +02:00
|
|
|
{
|
|
|
|
char buf[16];
|
2022-04-04 14:57:17 +02:00
|
|
|
FILE *fout = printQueryFout ? printQueryFout : pset.queryFout;
|
2006-08-13 23:10:04 +02:00
|
|
|
|
2006-08-29 17:19:51 +02:00
|
|
|
if (!pset.quiet)
|
2006-08-13 23:10:04 +02:00
|
|
|
{
|
|
|
|
if (pset.popt.topt.format == PRINT_HTML)
|
|
|
|
{
|
2022-04-04 14:57:17 +02:00
|
|
|
fputs("<p>", fout);
|
|
|
|
html_escaped_print(PQcmdStatus(result), fout);
|
|
|
|
fputs("</p>\n", fout);
|
2006-08-13 23:10:04 +02:00
|
|
|
}
|
|
|
|
else
|
2022-04-04 14:57:17 +02:00
|
|
|
fprintf(fout, "%s\n", PQcmdStatus(result));
|
2022-10-03 21:07:10 +02:00
|
|
|
fflush(fout);
|
2006-08-13 23:10:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (pset.logfile)
|
2022-02-10 12:03:35 +01:00
|
|
|
fprintf(pset.logfile, "%s\n", PQcmdStatus(result));
|
2006-08-13 23:10:04 +02:00
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
snprintf(buf, sizeof(buf), "%u", (unsigned int) PQoidValue(result));
|
2006-08-13 23:10:04 +02:00
|
|
|
SetVariable(pset.vars, "LASTOID", buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2003-10-06 03:11:12 +02:00
|
|
|
/*
|
2022-02-10 12:03:35 +01:00
|
|
|
* PrintQueryResult: print out (or store or execute) query result as required
|
2021-04-15 19:41:42 +02:00
|
|
|
*
|
|
|
|
* Note: Utility function for use by SendQuery() only.
|
2003-10-06 03:11:12 +02:00
|
|
|
*
|
2022-10-03 21:07:10 +02:00
|
|
|
* last is true if this is the last result of a command string.
|
|
|
|
* opt and printQueryFout are defined as for PrintQueryTuples.
|
|
|
|
* printStatusFout is where to send command status; NULL means pset.queryFout.
|
|
|
|
*
|
2003-10-06 03:11:12 +02:00
|
|
|
* Returns true if the query executed successfully, false otherwise.
|
|
|
|
*/
|
|
|
|
static bool
|
2022-10-03 21:07:10 +02:00
|
|
|
PrintQueryResult(PGresult *result, bool last,
|
|
|
|
const printQueryOpt *opt, FILE *printQueryFout,
|
|
|
|
FILE *printStatusFout)
|
2003-10-06 03:11:12 +02:00
|
|
|
{
|
2012-01-25 22:06:00 +01:00
|
|
|
bool success;
|
2006-08-13 23:10:04 +02:00
|
|
|
const char *cmdstatus;
|
2003-10-06 03:11:12 +02:00
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
if (!result)
|
2003-10-06 03:11:12 +02:00
|
|
|
return false;
|
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
switch (PQresultStatus(result))
|
2003-10-06 03:11:12 +02:00
|
|
|
{
|
|
|
|
case PGRES_TUPLES_OK:
|
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
|
|
|
/* store or execute or print the data ... */
|
2022-04-04 14:57:17 +02:00
|
|
|
if (last && pset.gset_prefix)
|
2022-02-10 12:03:35 +01:00
|
|
|
success = StoreQueryTuple(result);
|
2022-04-04 14:57:17 +02:00
|
|
|
else if (last && pset.gexec_flag)
|
2022-02-10 12:03:35 +01:00
|
|
|
success = ExecQueryTuples(result);
|
2022-04-04 14:57:17 +02:00
|
|
|
else if (last && pset.crosstab_flag)
|
2022-02-10 12:03:35 +01:00
|
|
|
success = PrintResultInCrosstab(result);
|
2022-04-04 14:57:17 +02:00
|
|
|
else if (last || pset.show_all_results)
|
|
|
|
success = PrintQueryTuples(result, opt, printQueryFout);
|
2013-02-02 23:06:38 +01:00
|
|
|
else
|
2022-04-04 14:57:17 +02:00
|
|
|
success = true;
|
|
|
|
|
2015-05-23 00:49:27 +02:00
|
|
|
/* if it's INSERT/UPDATE/DELETE RETURNING, also print status */
|
2022-04-04 14:57:17 +02:00
|
|
|
if (last || pset.show_all_results)
|
|
|
|
{
|
|
|
|
cmdstatus = PQcmdStatus(result);
|
|
|
|
if (strncmp(cmdstatus, "INSERT", 6) == 0 ||
|
|
|
|
strncmp(cmdstatus, "UPDATE", 6) == 0 ||
|
|
|
|
strncmp(cmdstatus, "DELETE", 6) == 0)
|
2022-10-03 21:07:10 +02:00
|
|
|
PrintQueryStatus(result, printStatusFout);
|
2022-04-04 14:57:17 +02:00
|
|
|
}
|
|
|
|
|
2003-10-06 03:11:12 +02:00
|
|
|
break;
|
|
|
|
|
2003-02-21 22:34:27 +01:00
|
|
|
case PGRES_COMMAND_OK:
|
2022-04-04 14:57:17 +02:00
|
|
|
if (last || pset.show_all_results)
|
2022-10-03 21:07:10 +02:00
|
|
|
PrintQueryStatus(result, printStatusFout);
|
2006-08-13 23:10:04 +02:00
|
|
|
success = true;
|
|
|
|
break;
|
2003-10-06 03:11:12 +02:00
|
|
|
|
|
|
|
case PGRES_EMPTY_QUERY:
|
|
|
|
success = true;
|
2003-08-04 02:43:34 +02:00
|
|
|
break;
|
2002-03-05 01:01:03 +01:00
|
|
|
|
2003-10-06 03:11:12 +02:00
|
|
|
case PGRES_COPY_OUT:
|
2003-02-21 22:34:27 +01:00
|
|
|
case PGRES_COPY_IN:
|
2022-04-04 14:57:17 +02:00
|
|
|
/* nothing to do here: already processed */
|
2003-10-06 03:11:12 +02:00
|
|
|
success = true;
|
2003-02-21 22:34:27 +01:00
|
|
|
break;
|
|
|
|
|
2012-01-25 22:06:00 +01:00
|
|
|
case PGRES_BAD_RESPONSE:
|
|
|
|
case PGRES_NONFATAL_ERROR:
|
|
|
|
case PGRES_FATAL_ERROR:
|
|
|
|
success = false;
|
|
|
|
break;
|
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
default:
|
2012-01-25 22:06:00 +01:00
|
|
|
success = false;
|
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_error("unexpected PQresultStatus: %d",
|
2022-02-10 12:03:35 +01:00
|
|
|
PQresultStatus(result));
|
2003-02-21 22:34:27 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SendQuery: send the query string to the backend
|
2022-02-10 12:03:35 +01:00
|
|
|
* (and print out result)
|
2003-03-20 07:00:12 +01:00
|
|
|
*
|
|
|
|
* Note: This is the "front door" way to send a query. That is, use it to
|
|
|
|
* send queries actually entered by the user. These queries will be subject to
|
|
|
|
* single step mode.
|
|
|
|
* To send "back door" queries (generated by slash commands, etc.) in a
|
|
|
|
* controlled way, use PSQLexec().
|
|
|
|
*
|
|
|
|
* Returns true if the query executed successfully, false otherwise.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
SendQuery(const char *query)
|
|
|
|
{
|
2021-10-12 21:14:50 +02:00
|
|
|
bool timing = pset.timing;
|
2006-08-30 00:25:08 +02:00
|
|
|
PGTransactionStatusType transaction_status;
|
|
|
|
double elapsed_msec = 0;
|
2013-02-02 20:21:24 +01:00
|
|
|
bool OK = false;
|
2016-04-15 04:54:26 +02:00
|
|
|
int i;
|
2013-02-02 20:21:24 +01:00
|
|
|
bool on_error_rollback_savepoint = false;
|
2022-03-31 19:57:21 +02:00
|
|
|
bool svpt_gone = false;
|
2005-10-15 04:49:52 +02:00
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
if (!pset.db)
|
2003-03-20 07:43:35 +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_error("You are currently not connected to a database.");
|
2013-02-02 20:21:24 +01:00
|
|
|
goto sendquery_cleanup;
|
2003-03-20 07:43:35 +01:00
|
|
|
}
|
2003-03-20 07:00:12 +01:00
|
|
|
|
2006-08-29 17:19:51 +02:00
|
|
|
if (pset.singlestep)
|
2003-03-20 07:43:35 +01:00
|
|
|
{
|
2003-03-20 07:00:12 +01:00
|
|
|
char buf[3];
|
|
|
|
|
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
|
|
|
fflush(stderr);
|
2005-02-22 05:43:23 +01:00
|
|
|
printf(_("***(Single step mode: verify command)*******************************************\n"
|
2003-03-20 07:00:12 +01:00
|
|
|
"%s\n"
|
|
|
|
"***(press return to proceed or enter x and return to cancel)********************\n"),
|
|
|
|
query);
|
|
|
|
fflush(stdout);
|
|
|
|
if (fgets(buf, sizeof(buf), stdin) != NULL)
|
|
|
|
if (buf[0] == 'x')
|
2013-02-02 20:21:24 +01:00
|
|
|
goto sendquery_cleanup;
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
if (cancel_pressed)
|
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
|
|
|
goto sendquery_cleanup;
|
2003-02-21 22:34:27 +01:00
|
|
|
}
|
2006-08-29 17:19:51 +02:00
|
|
|
else if (pset.echo == PSQL_ECHO_QUERIES)
|
2003-07-31 06:23:40 +02:00
|
|
|
{
|
2003-03-20 07:43:35 +01:00
|
|
|
puts(query);
|
2003-07-31 06:23:40 +02:00
|
|
|
fflush(stdout);
|
|
|
|
}
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2005-06-14 04:57:45 +02:00
|
|
|
if (pset.logfile)
|
|
|
|
{
|
2005-10-04 21:01:18 +02:00
|
|
|
fprintf(pset.logfile,
|
|
|
|
_("********* QUERY **********\n"
|
|
|
|
"%s\n"
|
|
|
|
"**************************\n\n"), query);
|
2005-06-14 04:57:45 +02:00
|
|
|
fflush(pset.logfile);
|
|
|
|
}
|
|
|
|
|
2019-12-02 03:18:56 +01:00
|
|
|
SetCancelConn(pset.db);
|
2003-02-21 22:34:27 +01:00
|
|
|
|
2005-04-28 15:09:59 +02:00
|
|
|
transaction_status = PQtransactionStatus(pset.db);
|
|
|
|
|
|
|
|
if (transaction_status == PQTRANS_IDLE &&
|
2006-08-29 17:19:51 +02:00
|
|
|
!pset.autocommit &&
|
2004-09-20 20:51:19 +02:00
|
|
|
!command_no_begin(query))
|
2003-06-28 02:12:40 +02:00
|
|
|
{
|
2022-03-31 19:57:21 +02:00
|
|
|
PGresult *result;
|
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
result = PQexec(pset.db, "BEGIN");
|
|
|
|
if (PQresultStatus(result) != PGRES_COMMAND_OK)
|
2003-06-28 02:12:40 +02: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_info("%s", PQerrorMessage(pset.db));
|
2022-02-10 12:03:35 +01:00
|
|
|
ClearOrSaveResult(result);
|
2013-02-02 20:21:24 +01:00
|
|
|
goto sendquery_cleanup;
|
2003-06-28 02:12:40 +02:00
|
|
|
}
|
2022-02-10 12:03:35 +01:00
|
|
|
ClearOrSaveResult(result);
|
2005-09-20 23:43:08 +02:00
|
|
|
transaction_status = PQtransactionStatus(pset.db);
|
2003-06-28 02:12:40 +02:00
|
|
|
}
|
2005-09-20 23:43:08 +02:00
|
|
|
|
|
|
|
if (transaction_status == PQTRANS_INTRANS &&
|
2006-08-29 17:19:51 +02:00
|
|
|
pset.on_error_rollback != PSQL_ERROR_ROLLBACK_OFF &&
|
2005-09-20 23:43:08 +02:00
|
|
|
(pset.cur_cmd_interactive ||
|
2006-08-29 17:19:51 +02:00
|
|
|
pset.on_error_rollback == PSQL_ERROR_ROLLBACK_ON))
|
2005-04-28 15:09:59 +02:00
|
|
|
{
|
2022-03-31 19:57:21 +02:00
|
|
|
PGresult *result;
|
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
result = PQexec(pset.db, "SAVEPOINT pg_psql_temporary_savepoint");
|
|
|
|
if (PQresultStatus(result) != PGRES_COMMAND_OK)
|
2005-04-28 15:09:59 +02:00
|
|
|
{
|
2021-12-16 20:02:28 +01:00
|
|
|
pg_log_info("%s", PQerrorMessage(pset.db));
|
2022-02-10 12:03:35 +01:00
|
|
|
ClearOrSaveResult(result);
|
2021-12-16 20:02:28 +01:00
|
|
|
goto sendquery_cleanup;
|
2005-04-28 15:09:59 +02:00
|
|
|
}
|
2022-02-10 12:03:35 +01:00
|
|
|
ClearOrSaveResult(result);
|
2021-12-16 20:02:28 +01:00
|
|
|
on_error_rollback_savepoint = true;
|
2005-04-28 15:09:59 +02:00
|
|
|
}
|
2003-06-28 02:12:40 +02:00
|
|
|
|
2017-09-06 00:17:47 +02:00
|
|
|
if (pset.gdesc_flag)
|
|
|
|
{
|
|
|
|
/* Describe query's result columns, without executing it */
|
|
|
|
OK = DescribeQuery(query, &elapsed_msec);
|
|
|
|
}
|
|
|
|
else if (pset.fetch_count <= 0 || pset.gexec_flag ||
|
|
|
|
pset.crosstab_flag || !is_select_command(query))
|
2006-08-30 00:25:08 +02:00
|
|
|
{
|
|
|
|
/* Default fetch-it-all-and-print mode */
|
2022-10-22 09:41:38 +02:00
|
|
|
OK = (ExecQueryAndProcessResults(query, &elapsed_msec, &svpt_gone, false, NULL, NULL) > 0);
|
2006-08-30 00:25:08 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Fetch-in-segments mode */
|
|
|
|
OK = ExecQueryUsingCursor(query, &elapsed_msec);
|
|
|
|
}
|
2003-10-06 03:11:12 +02:00
|
|
|
|
2014-07-10 07:27:54 +02:00
|
|
|
if (!OK && pset.echo == PSQL_ECHO_ERRORS)
|
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_info("STATEMENT: %s", query);
|
2014-07-10 07:27:54 +02:00
|
|
|
|
2005-04-28 15:09:59 +02:00
|
|
|
/* If we made a temporary savepoint, possibly release/rollback */
|
|
|
|
if (on_error_rollback_savepoint)
|
|
|
|
{
|
2012-01-25 22:06:00 +01:00
|
|
|
const char *svptcmd = NULL;
|
2006-06-30 17:06:05 +02:00
|
|
|
|
2005-04-28 15:09:59 +02:00
|
|
|
transaction_status = PQtransactionStatus(pset.db);
|
|
|
|
|
2012-01-25 22:06:00 +01:00
|
|
|
switch (transaction_status)
|
2008-08-16 03:36:35 +02:00
|
|
|
{
|
2012-01-25 22:06:00 +01:00
|
|
|
case PQTRANS_INERROR:
|
|
|
|
/* We always rollback on an error */
|
|
|
|
svptcmd = "ROLLBACK TO pg_psql_temporary_savepoint";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PQTRANS_IDLE:
|
|
|
|
/* If they are no longer in a transaction, then do nothing */
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PQTRANS_INTRANS:
|
2022-05-12 21:17:30 +02:00
|
|
|
|
2012-01-25 22:06:00 +01:00
|
|
|
/*
|
2022-03-31 19:57:21 +02:00
|
|
|
* Release our savepoint, but do nothing if they are messing
|
|
|
|
* with savepoints themselves
|
2012-01-25 22:06:00 +01:00
|
|
|
*/
|
2022-03-31 19:57:21 +02:00
|
|
|
if (!svpt_gone)
|
2012-01-25 22:06:00 +01:00
|
|
|
svptcmd = "RELEASE pg_psql_temporary_savepoint";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PQTRANS_ACTIVE:
|
|
|
|
case PQTRANS_UNKNOWN:
|
|
|
|
default:
|
|
|
|
OK = false;
|
2012-03-07 22:56:42 +01:00
|
|
|
/* PQTRANS_UNKNOWN is expected given a broken connection. */
|
|
|
|
if (transaction_status != PQTRANS_UNKNOWN || ConnectionUp())
|
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_error("unexpected transaction status (%d)",
|
2012-03-07 22:56:42 +01:00
|
|
|
transaction_status);
|
2012-01-25 22:06:00 +01:00
|
|
|
break;
|
2005-04-28 15:09:59 +02:00
|
|
|
}
|
2008-08-16 03:36:35 +02:00
|
|
|
|
|
|
|
if (svptcmd)
|
2005-04-28 15:09:59 +02:00
|
|
|
{
|
2008-08-16 03:36:35 +02:00
|
|
|
PGresult *svptres;
|
|
|
|
|
|
|
|
svptres = PQexec(pset.db, svptcmd);
|
|
|
|
if (PQresultStatus(svptres) != PGRES_COMMAND_OK)
|
|
|
|
{
|
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_info("%s", PQerrorMessage(pset.db));
|
2016-04-03 18:29:55 +02:00
|
|
|
ClearOrSaveResult(svptres);
|
2013-02-02 20:21:24 +01:00
|
|
|
OK = false;
|
2008-08-16 03:36:35 +02:00
|
|
|
|
2013-02-02 20:21:24 +01:00
|
|
|
goto sendquery_cleanup;
|
2008-08-16 03:36:35 +02:00
|
|
|
}
|
2006-06-30 17:06:05 +02:00
|
|
|
PQclear(svptres);
|
2005-04-28 15:09:59 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-10-06 03:11:12 +02:00
|
|
|
/* Possible microtiming output */
|
2021-10-12 21:14:50 +02:00
|
|
|
if (timing)
|
2016-09-03 21:29:03 +02:00
|
|
|
PrintTiming(elapsed_msec);
|
2003-10-06 03:11:12 +02:00
|
|
|
|
2003-09-16 19:59:02 +02:00
|
|
|
/* check for events that may occur during query execution */
|
|
|
|
|
|
|
|
if (pset.encoding != PQclientEncoding(pset.db) &&
|
|
|
|
PQclientEncoding(pset.db) >= 0)
|
|
|
|
{
|
|
|
|
/* track effects of SET CLIENT_ENCODING */
|
|
|
|
pset.encoding = PQclientEncoding(pset.db);
|
|
|
|
pset.popt.topt.encoding = pset.encoding;
|
|
|
|
SetVariable(pset.vars, "ENCODING",
|
|
|
|
pg_encoding_to_char(pset.encoding));
|
|
|
|
}
|
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
PrintNotifications();
|
2003-09-16 19:59:02 +02:00
|
|
|
|
2013-02-02 20:21:24 +01:00
|
|
|
/* perform cleanup that should occur after any attempted query */
|
|
|
|
|
|
|
|
sendquery_cleanup:
|
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
/* global cancellation reset */
|
|
|
|
ResetCancelConn();
|
|
|
|
|
2013-02-02 20:21:24 +01:00
|
|
|
/* reset \g's output-to-filename trigger */
|
|
|
|
if (pset.gfname)
|
|
|
|
{
|
|
|
|
free(pset.gfname);
|
|
|
|
pset.gfname = NULL;
|
|
|
|
}
|
|
|
|
|
2020-04-07 23:46:29 +02:00
|
|
|
/* restore print settings if \g changed them */
|
|
|
|
if (pset.gsavepopt)
|
|
|
|
{
|
|
|
|
restorePsetInfo(&pset.popt, pset.gsavepopt);
|
|
|
|
pset.gsavepopt = NULL;
|
|
|
|
}
|
2017-03-07 15:31:52 +01:00
|
|
|
|
2022-11-15 13:50:27 +01:00
|
|
|
/* clean up after \bind */
|
|
|
|
if (pset.bind_flag)
|
|
|
|
{
|
|
|
|
for (i = 0; i < pset.bind_nparams; i++)
|
|
|
|
free(pset.bind_params[i]);
|
|
|
|
free(pset.bind_params);
|
|
|
|
pset.bind_params = NULL;
|
|
|
|
pset.bind_flag = false;
|
|
|
|
}
|
|
|
|
|
2013-02-02 23:06:38 +01:00
|
|
|
/* reset \gset trigger */
|
|
|
|
if (pset.gset_prefix)
|
|
|
|
{
|
|
|
|
free(pset.gset_prefix);
|
|
|
|
pset.gset_prefix = NULL;
|
|
|
|
}
|
|
|
|
|
2017-09-06 00:17:47 +02:00
|
|
|
/* reset \gdesc trigger */
|
|
|
|
pset.gdesc_flag = false;
|
|
|
|
|
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
|
|
|
/* reset \gexec trigger */
|
|
|
|
pset.gexec_flag = false;
|
|
|
|
|
2016-04-09 01:23:18 +02:00
|
|
|
/* reset \crosstabview trigger */
|
|
|
|
pset.crosstab_flag = false;
|
2016-04-15 04:54:26 +02:00
|
|
|
for (i = 0; i < lengthof(pset.ctv_args); i++)
|
2016-04-09 01:23:18 +02:00
|
|
|
{
|
2016-04-15 04:54:26 +02:00
|
|
|
pg_free(pset.ctv_args[i]);
|
|
|
|
pset.ctv_args[i] = NULL;
|
2016-04-09 01:23:18 +02:00
|
|
|
}
|
|
|
|
|
2003-03-20 07:00:12 +01:00
|
|
|
return OK;
|
1999-11-04 22:56:02 +01:00
|
|
|
}
|
2003-03-20 07:43:35 +01:00
|
|
|
|
2004-09-20 20:51:19 +02:00
|
|
|
|
2017-09-06 00:17:47 +02:00
|
|
|
/*
|
|
|
|
* DescribeQuery: describe the result columns of a query, without executing it
|
|
|
|
*
|
|
|
|
* Returns true if the operation executed successfully, false otherwise.
|
|
|
|
*
|
|
|
|
* If pset.timing is on, total query time (exclusive of result-printing) is
|
|
|
|
* stored into *elapsed_msec.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
DescribeQuery(const char *query, double *elapsed_msec)
|
|
|
|
{
|
2021-10-12 21:14:50 +02:00
|
|
|
bool timing = pset.timing;
|
2022-02-10 12:03:35 +01:00
|
|
|
PGresult *result;
|
2017-09-06 00:17:47 +02:00
|
|
|
bool OK;
|
|
|
|
instr_time before,
|
|
|
|
after;
|
|
|
|
|
|
|
|
*elapsed_msec = 0;
|
|
|
|
|
2021-10-12 21:14:50 +02:00
|
|
|
if (timing)
|
2017-09-06 00:17:47 +02:00
|
|
|
INSTR_TIME_SET_CURRENT(before);
|
2023-01-21 06:16:47 +01:00
|
|
|
else
|
|
|
|
INSTR_TIME_SET_ZERO(before);
|
2017-09-06 00:17:47 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* To parse the query but not execute it, we prepare it, using the unnamed
|
|
|
|
* prepared statement. This is invisible to psql users, since there's no
|
|
|
|
* way to access the unnamed prepared statement from psql user space. The
|
|
|
|
* next Parse or Query protocol message would overwrite the statement
|
|
|
|
* anyway. (So there's no great need to clear it when done, which is a
|
|
|
|
* good thing because libpq provides no easy way to do that.)
|
|
|
|
*/
|
2022-02-10 12:03:35 +01:00
|
|
|
result = PQprepare(pset.db, "", query, 0, NULL);
|
|
|
|
if (PQresultStatus(result) != PGRES_COMMAND_OK)
|
2017-09-06 00:17:47 +02: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_info("%s", PQerrorMessage(pset.db));
|
2022-02-10 12:03:35 +01:00
|
|
|
SetResultVariables(result, false);
|
|
|
|
ClearOrSaveResult(result);
|
2017-09-06 00:17:47 +02:00
|
|
|
return false;
|
|
|
|
}
|
2022-02-10 12:03:35 +01:00
|
|
|
PQclear(result);
|
2017-09-06 00:17:47 +02:00
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
result = PQdescribePrepared(pset.db, "");
|
2022-04-04 14:57:17 +02:00
|
|
|
OK = AcceptResult(result, true) &&
|
2022-02-10 12:03:35 +01:00
|
|
|
(PQresultStatus(result) == PGRES_COMMAND_OK);
|
|
|
|
if (OK && result)
|
2017-09-06 00:17:47 +02:00
|
|
|
{
|
2022-02-10 12:03:35 +01:00
|
|
|
if (PQnfields(result) > 0)
|
2017-09-06 00:17:47 +02:00
|
|
|
{
|
|
|
|
PQExpBufferData buf;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
initPQExpBuffer(&buf);
|
|
|
|
|
|
|
|
printfPQExpBuffer(&buf,
|
|
|
|
"SELECT name AS \"%s\", pg_catalog.format_type(tp, tpm) AS \"%s\"\n"
|
|
|
|
"FROM (VALUES ",
|
|
|
|
gettext_noop("Column"),
|
|
|
|
gettext_noop("Type"));
|
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
for (i = 0; i < PQnfields(result); i++)
|
2017-09-06 00:17:47 +02:00
|
|
|
{
|
|
|
|
const char *name;
|
|
|
|
char *escname;
|
|
|
|
|
|
|
|
if (i > 0)
|
|
|
|
appendPQExpBufferStr(&buf, ",");
|
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
name = PQfname(result, i);
|
2017-09-06 00:17:47 +02:00
|
|
|
escname = PQescapeLiteral(pset.db, name, strlen(name));
|
|
|
|
|
|
|
|
if (escname == NULL)
|
|
|
|
{
|
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_info("%s", PQerrorMessage(pset.db));
|
2022-02-10 12:03:35 +01:00
|
|
|
PQclear(result);
|
2017-09-06 00:17:47 +02:00
|
|
|
termPQExpBuffer(&buf);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
appendPQExpBuffer(&buf, "(%s, '%u'::pg_catalog.oid, %d)",
|
|
|
|
escname,
|
2022-02-10 12:03:35 +01:00
|
|
|
PQftype(result, i),
|
|
|
|
PQfmod(result, i));
|
2017-09-06 00:17:47 +02:00
|
|
|
|
|
|
|
PQfreemem(escname);
|
|
|
|
}
|
|
|
|
|
|
|
|
appendPQExpBufferStr(&buf, ") s(name, tp, tpm)");
|
2022-02-10 12:03:35 +01:00
|
|
|
PQclear(result);
|
2017-09-06 00:17:47 +02:00
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
result = PQexec(pset.db, buf.data);
|
2022-04-04 14:57:17 +02:00
|
|
|
OK = AcceptResult(result, true);
|
2017-09-06 00:17:47 +02:00
|
|
|
|
2021-10-12 21:14:50 +02:00
|
|
|
if (timing)
|
2017-09-06 00:17:47 +02:00
|
|
|
{
|
|
|
|
INSTR_TIME_SET_CURRENT(after);
|
|
|
|
INSTR_TIME_SUBTRACT(after, before);
|
|
|
|
*elapsed_msec += INSTR_TIME_GET_MILLISEC(after);
|
|
|
|
}
|
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
if (OK && result)
|
2022-10-03 21:07:10 +02:00
|
|
|
OK = PrintQueryResult(result, true, NULL, NULL, NULL);
|
2017-09-06 00:17:47 +02:00
|
|
|
|
|
|
|
termPQExpBuffer(&buf);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
fprintf(pset.queryFout,
|
|
|
|
_("The command has no result, or the result has no columns.\n"));
|
|
|
|
}
|
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
SetResultVariables(result, OK);
|
|
|
|
ClearOrSaveResult(result);
|
2017-09-06 00:17:47 +02:00
|
|
|
|
|
|
|
return OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2022-03-31 19:57:21 +02:00
|
|
|
/*
|
2022-04-04 14:57:17 +02:00
|
|
|
* ExecQueryAndProcessResults: utility function for use by SendQuery()
|
|
|
|
* and PSQLexecWatch().
|
|
|
|
*
|
|
|
|
* Sends query and cycles through PGresult objects.
|
|
|
|
*
|
2022-10-03 21:07:10 +02:00
|
|
|
* If our command string contained a COPY FROM STDIN or COPY TO STDOUT, the
|
|
|
|
* PGresult associated with these commands must be processed by providing an
|
|
|
|
* input or output stream. In that event, we'll marshal data for the COPY.
|
2022-04-04 14:57:17 +02:00
|
|
|
*
|
|
|
|
* For other commands, the results are processed normally, depending on their
|
|
|
|
* status.
|
|
|
|
*
|
|
|
|
* Returns 1 on complete success, 0 on interrupt and -1 or errors. Possible
|
|
|
|
* failure modes include purely client-side problems; check the transaction
|
|
|
|
* status for the server-side opinion.
|
|
|
|
*
|
|
|
|
* Note that on a combined query, failure does not mean that nothing was
|
|
|
|
* committed.
|
2022-03-31 19:57:21 +02:00
|
|
|
*/
|
2022-04-04 14:57:17 +02:00
|
|
|
static int
|
2022-10-03 21:07:10 +02:00
|
|
|
ExecQueryAndProcessResults(const char *query,
|
|
|
|
double *elapsed_msec, bool *svpt_gone_p,
|
|
|
|
bool is_watch,
|
|
|
|
const printQueryOpt *opt, FILE *printQueryFout)
|
2022-03-31 19:57:21 +02:00
|
|
|
{
|
|
|
|
bool timing = pset.timing;
|
2022-04-04 14:57:17 +02:00
|
|
|
bool success;
|
2022-03-31 19:57:21 +02:00
|
|
|
instr_time before,
|
|
|
|
after;
|
|
|
|
PGresult *result;
|
2022-10-03 21:07:10 +02:00
|
|
|
FILE *gfile_fout = NULL;
|
|
|
|
bool gfile_is_pipe = false;
|
2022-03-31 19:57:21 +02:00
|
|
|
|
|
|
|
if (timing)
|
|
|
|
INSTR_TIME_SET_CURRENT(before);
|
2023-01-21 06:16:47 +01:00
|
|
|
else
|
|
|
|
INSTR_TIME_SET_ZERO(before);
|
2022-03-31 19:57:21 +02:00
|
|
|
|
2022-11-15 13:50:27 +01:00
|
|
|
if (pset.bind_flag)
|
2023-05-19 23:24:48 +02:00
|
|
|
success = PQsendQueryParams(pset.db, query, pset.bind_nparams, NULL, (const char *const *) pset.bind_params, NULL, NULL, 0);
|
2022-11-15 13:50:27 +01:00
|
|
|
else
|
|
|
|
success = PQsendQuery(pset.db, query);
|
2022-03-31 19:57:21 +02:00
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
if (!success)
|
2022-03-31 19:57:21 +02:00
|
|
|
{
|
2022-04-04 14:57:17 +02:00
|
|
|
const char *error = PQerrorMessage(pset.db);
|
2022-03-31 19:57:21 +02:00
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
if (strlen(error))
|
|
|
|
pg_log_info("%s", error);
|
|
|
|
|
|
|
|
CheckConnection();
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
2022-03-31 19:57:21 +02:00
|
|
|
|
|
|
|
/*
|
2022-04-04 14:57:17 +02:00
|
|
|
* If SIGINT is sent while the query is processing, the interrupt will be
|
|
|
|
* consumed. The user's intention, though, is to cancel the entire watch
|
|
|
|
* process, so detect a sent cancellation request and exit in this case.
|
2022-03-31 19:57:21 +02:00
|
|
|
*/
|
2022-04-04 14:57:17 +02:00
|
|
|
if (is_watch && cancel_pressed)
|
2022-03-31 19:57:21 +02:00
|
|
|
{
|
2022-04-04 14:57:17 +02:00
|
|
|
ClearOrSaveAllResults();
|
|
|
|
return 0;
|
2022-03-31 19:57:21 +02:00
|
|
|
}
|
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
/* first result */
|
|
|
|
result = PQgetResult(pset.db);
|
|
|
|
|
|
|
|
while (result != NULL)
|
|
|
|
{
|
|
|
|
ExecStatusType result_status;
|
|
|
|
PGresult *next_result;
|
|
|
|
bool last;
|
|
|
|
|
|
|
|
if (!AcceptResult(result, false))
|
|
|
|
{
|
|
|
|
/*
|
2023-01-11 07:16:38 +01:00
|
|
|
* Some error occurred, either a server-side failure or a failure
|
2022-04-04 14:57:17 +02:00
|
|
|
* to submit the command string. Record that.
|
|
|
|
*/
|
|
|
|
const char *error = PQresultErrorMessage(result);
|
|
|
|
|
|
|
|
if (strlen(error))
|
|
|
|
pg_log_info("%s", error);
|
|
|
|
|
|
|
|
CheckConnection();
|
|
|
|
if (!is_watch)
|
|
|
|
SetResultVariables(result, false);
|
|
|
|
|
|
|
|
/* keep the result status before clearing it */
|
|
|
|
result_status = PQresultStatus(result);
|
|
|
|
ClearOrSaveResult(result);
|
|
|
|
success = false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* switch to next result
|
|
|
|
*/
|
|
|
|
if (result_status == PGRES_COPY_BOTH ||
|
|
|
|
result_status == PGRES_COPY_OUT ||
|
|
|
|
result_status == PGRES_COPY_IN)
|
2022-05-12 21:17:30 +02:00
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
/*
|
|
|
|
* For some obscure reason PQgetResult does *not* return a
|
|
|
|
* NULL in copy cases despite the result having been cleared,
|
|
|
|
* but keeps returning an "empty" result that we have to
|
|
|
|
* ignore manually.
|
|
|
|
*/
|
|
|
|
result = NULL;
|
|
|
|
else
|
|
|
|
result = PQgetResult(pset.db);
|
|
|
|
|
2022-05-23 10:07:36 +02:00
|
|
|
/*
|
|
|
|
* Get current timing measure in case an error occurs
|
|
|
|
*/
|
|
|
|
if (timing)
|
|
|
|
{
|
|
|
|
INSTR_TIME_SET_CURRENT(after);
|
|
|
|
INSTR_TIME_SUBTRACT(after, before);
|
|
|
|
*elapsed_msec = INSTR_TIME_GET_MILLISEC(after);
|
|
|
|
}
|
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
else if (svpt_gone_p && !*svpt_gone_p)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Check if the user ran any command that would destroy our
|
|
|
|
* internal savepoint: If the user did COMMIT AND CHAIN, RELEASE
|
|
|
|
* or ROLLBACK, our savepoint is gone. If they issued a SAVEPOINT,
|
|
|
|
* releasing ours would remove theirs.
|
|
|
|
*/
|
|
|
|
const char *cmd = PQcmdStatus(result);
|
2022-05-12 21:17:30 +02:00
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
*svpt_gone_p = (strcmp(cmd, "COMMIT") == 0 ||
|
|
|
|
strcmp(cmd, "SAVEPOINT") == 0 ||
|
|
|
|
strcmp(cmd, "RELEASE") == 0 ||
|
|
|
|
strcmp(cmd, "ROLLBACK") == 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
result_status = PQresultStatus(result);
|
|
|
|
|
|
|
|
/* must handle COPY before changing the current result */
|
|
|
|
Assert(result_status != PGRES_COPY_BOTH);
|
|
|
|
if (result_status == PGRES_COPY_IN ||
|
|
|
|
result_status == PGRES_COPY_OUT)
|
|
|
|
{
|
2022-10-03 21:07:10 +02:00
|
|
|
FILE *copy_stream = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For COPY OUT, direct the output to the default place (probably
|
|
|
|
* a pager pipe) for \watch, or to pset.copyStream for \copy,
|
|
|
|
* otherwise to pset.gfname if that's set, otherwise to
|
|
|
|
* pset.queryFout.
|
|
|
|
*/
|
|
|
|
if (result_status == PGRES_COPY_OUT)
|
2022-04-04 14:57:17 +02:00
|
|
|
{
|
2022-10-03 21:07:10 +02:00
|
|
|
if (is_watch)
|
|
|
|
{
|
|
|
|
/* invoked by \watch */
|
|
|
|
copy_stream = printQueryFout ? printQueryFout : pset.queryFout;
|
|
|
|
}
|
|
|
|
else if (pset.copyStream)
|
|
|
|
{
|
|
|
|
/* invoked by \copy */
|
|
|
|
copy_stream = pset.copyStream;
|
|
|
|
}
|
|
|
|
else if (pset.gfname)
|
|
|
|
{
|
|
|
|
/* send to \g file, which we may have opened already */
|
|
|
|
if (gfile_fout == NULL)
|
|
|
|
{
|
|
|
|
if (openQueryOutputFile(pset.gfname,
|
|
|
|
&gfile_fout, &gfile_is_pipe))
|
|
|
|
{
|
|
|
|
if (gfile_is_pipe)
|
|
|
|
disable_sigpipe_trap();
|
|
|
|
copy_stream = gfile_fout;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
success = false;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
copy_stream = gfile_fout;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* fall back to the generic query output stream */
|
|
|
|
copy_stream = pset.queryFout;
|
|
|
|
}
|
2022-04-04 14:57:17 +02:00
|
|
|
}
|
|
|
|
|
2022-10-03 21:07:10 +02:00
|
|
|
/*
|
|
|
|
* Even if the output stream could not be opened, we call
|
|
|
|
* HandleCopyResult() with a NULL output stream to collect and
|
|
|
|
* discard the COPY data.
|
|
|
|
*/
|
|
|
|
success &= HandleCopyResult(&result, copy_stream);
|
2022-04-04 14:57:17 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check PQgetResult() again. In the typical case of a single-command
|
|
|
|
* string, it will return NULL. Otherwise, we'll have other results
|
|
|
|
* to process. We need to do that to check whether this is the last.
|
|
|
|
*/
|
|
|
|
next_result = PQgetResult(pset.db);
|
|
|
|
last = (next_result == NULL);
|
|
|
|
|
|
|
|
/*
|
2022-05-23 10:07:36 +02:00
|
|
|
* Update current timing measure.
|
2022-04-04 14:57:17 +02:00
|
|
|
*
|
|
|
|
* It will include the display of previous results, if any. This
|
|
|
|
* cannot be helped because the server goes on processing further
|
|
|
|
* queries anyway while the previous ones are being displayed. The
|
|
|
|
* parallel execution of the client display hides the server time when
|
|
|
|
* it is shorter.
|
|
|
|
*
|
|
|
|
* With combined queries, timing must be understood as an upper bound
|
|
|
|
* of the time spent processing them.
|
|
|
|
*/
|
2022-05-23 10:07:36 +02:00
|
|
|
if (timing)
|
2022-04-04 14:57:17 +02:00
|
|
|
{
|
|
|
|
INSTR_TIME_SET_CURRENT(after);
|
|
|
|
INSTR_TIME_SUBTRACT(after, before);
|
|
|
|
*elapsed_msec = INSTR_TIME_GET_MILLISEC(after);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* this may or may not print something depending on settings */
|
|
|
|
if (result != NULL)
|
2022-10-03 21:07:10 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If results need to be printed into the file specified by \g,
|
|
|
|
* open it, unless we already did. Note that when pset.gfname is
|
|
|
|
* set, the passed-in value of printQueryFout is not used for
|
|
|
|
* tuple output, but it's still used for status output.
|
|
|
|
*/
|
|
|
|
FILE *tuples_fout = printQueryFout;
|
|
|
|
bool do_print = true;
|
|
|
|
|
|
|
|
if (PQresultStatus(result) == PGRES_TUPLES_OK &&
|
|
|
|
pset.gfname)
|
|
|
|
{
|
|
|
|
if (gfile_fout == NULL)
|
|
|
|
{
|
|
|
|
if (openQueryOutputFile(pset.gfname,
|
|
|
|
&gfile_fout, &gfile_is_pipe))
|
|
|
|
{
|
|
|
|
if (gfile_is_pipe)
|
|
|
|
disable_sigpipe_trap();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
success = do_print = false;
|
|
|
|
}
|
|
|
|
tuples_fout = gfile_fout;
|
|
|
|
}
|
|
|
|
if (do_print)
|
|
|
|
success &= PrintQueryResult(result, last, opt,
|
|
|
|
tuples_fout, printQueryFout);
|
|
|
|
}
|
2022-04-04 14:57:17 +02:00
|
|
|
|
|
|
|
/* set variables on last result if all went well */
|
|
|
|
if (!is_watch && last && success)
|
|
|
|
SetResultVariables(result, true);
|
|
|
|
|
|
|
|
ClearOrSaveResult(result);
|
|
|
|
result = next_result;
|
|
|
|
|
|
|
|
if (cancel_pressed)
|
|
|
|
{
|
|
|
|
ClearOrSaveAllResults();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-10-03 21:07:10 +02:00
|
|
|
/* close \g file if we opened it */
|
|
|
|
if (gfile_fout)
|
|
|
|
{
|
|
|
|
if (gfile_is_pipe)
|
|
|
|
{
|
2023-04-06 23:33:38 +02:00
|
|
|
SetShellResultVariables(pclose(gfile_fout));
|
2022-10-03 21:07:10 +02:00
|
|
|
restore_sigpipe_trap();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
fclose(gfile_fout);
|
|
|
|
}
|
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
/* may need this to recover from conn loss during COPY */
|
|
|
|
if (!CheckConnection())
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
return cancel_pressed ? 0 : success ? 1 : -1;
|
2022-03-31 19:57:21 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-08-30 00:25:08 +02:00
|
|
|
/*
|
|
|
|
* ExecQueryUsingCursor: run a SELECT-like query using a cursor
|
|
|
|
*
|
|
|
|
* This feature allows result sets larger than RAM to be dealt with.
|
|
|
|
*
|
|
|
|
* Returns true if the query executed successfully, false otherwise.
|
|
|
|
*
|
|
|
|
* If pset.timing is on, total query time (exclusive of result-printing) is
|
|
|
|
* stored into *elapsed_msec.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
ExecQueryUsingCursor(const char *query, double *elapsed_msec)
|
|
|
|
{
|
|
|
|
bool OK = true;
|
2022-02-10 12:03:35 +01:00
|
|
|
PGresult *result;
|
2006-08-30 00:25:08 +02:00
|
|
|
PQExpBufferData buf;
|
|
|
|
printQueryOpt my_popt = pset.popt;
|
2021-10-12 21:14:50 +02:00
|
|
|
bool timing = pset.timing;
|
2015-12-03 20:28:58 +01:00
|
|
|
FILE *fout;
|
|
|
|
bool is_pipe;
|
|
|
|
bool is_pager = false;
|
2006-08-30 00:25:08 +02:00
|
|
|
bool started_txn = false;
|
2017-09-13 01:27:48 +02:00
|
|
|
int64 total_tuples = 0;
|
2006-08-30 00:25:08 +02:00
|
|
|
int ntuples;
|
2013-02-02 23:06:38 +01:00
|
|
|
int fetch_count;
|
2006-08-30 00:25:08 +02:00
|
|
|
char fetch_cmd[64];
|
2008-05-14 21:10:29 +02:00
|
|
|
instr_time before,
|
2006-08-30 00:25:08 +02:00
|
|
|
after;
|
2010-05-28 22:02:32 +02:00
|
|
|
int flush_error;
|
2006-08-30 00:25:08 +02:00
|
|
|
|
|
|
|
*elapsed_msec = 0;
|
|
|
|
|
|
|
|
/* initialize print options for partial table output */
|
|
|
|
my_popt.topt.start_table = true;
|
|
|
|
my_popt.topt.stop_table = false;
|
|
|
|
my_popt.topt.prior_records = 0;
|
|
|
|
|
2021-10-12 21:14:50 +02:00
|
|
|
if (timing)
|
2008-05-14 21:10:29 +02:00
|
|
|
INSTR_TIME_SET_CURRENT(before);
|
2023-01-21 06:16:47 +01:00
|
|
|
else
|
|
|
|
INSTR_TIME_SET_ZERO(before);
|
2006-08-30 00:25:08 +02:00
|
|
|
|
|
|
|
/* if we're not in a transaction, start one */
|
|
|
|
if (PQtransactionStatus(pset.db) == PQTRANS_IDLE)
|
|
|
|
{
|
2022-02-10 12:03:35 +01:00
|
|
|
result = PQexec(pset.db, "BEGIN");
|
2022-04-04 14:57:17 +02:00
|
|
|
OK = AcceptResult(result, true) &&
|
2022-02-10 12:03:35 +01:00
|
|
|
(PQresultStatus(result) == PGRES_COMMAND_OK);
|
|
|
|
ClearOrSaveResult(result);
|
2006-08-30 00:25:08 +02:00
|
|
|
if (!OK)
|
|
|
|
return false;
|
|
|
|
started_txn = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Send DECLARE CURSOR */
|
|
|
|
initPQExpBuffer(&buf);
|
|
|
|
appendPQExpBuffer(&buf, "DECLARE _psql_cursor NO SCROLL CURSOR FOR\n%s",
|
|
|
|
query);
|
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
result = PQexec(pset.db, buf.data);
|
2022-04-04 14:57:17 +02:00
|
|
|
OK = AcceptResult(result, true) &&
|
2022-02-10 12:03:35 +01:00
|
|
|
(PQresultStatus(result) == PGRES_COMMAND_OK);
|
2017-09-13 01:27:48 +02:00
|
|
|
if (!OK)
|
2022-02-10 12:03:35 +01:00
|
|
|
SetResultVariables(result, OK);
|
|
|
|
ClearOrSaveResult(result);
|
2006-08-30 00:25:08 +02:00
|
|
|
termPQExpBuffer(&buf);
|
|
|
|
if (!OK)
|
|
|
|
goto cleanup;
|
|
|
|
|
2021-10-12 21:14:50 +02:00
|
|
|
if (timing)
|
2006-08-30 00:25:08 +02:00
|
|
|
{
|
2008-05-14 21:10:29 +02:00
|
|
|
INSTR_TIME_SET_CURRENT(after);
|
|
|
|
INSTR_TIME_SUBTRACT(after, before);
|
|
|
|
*elapsed_msec += INSTR_TIME_GET_MILLISEC(after);
|
2006-08-30 00:25:08 +02:00
|
|
|
}
|
|
|
|
|
2013-02-02 23:06:38 +01:00
|
|
|
/*
|
|
|
|
* In \gset mode, we force the fetch count to be 2, so that we will throw
|
|
|
|
* the appropriate error if the query returns more than one row.
|
|
|
|
*/
|
|
|
|
if (pset.gset_prefix)
|
|
|
|
fetch_count = 2;
|
|
|
|
else
|
|
|
|
fetch_count = pset.fetch_count;
|
|
|
|
|
2006-08-30 00:25:08 +02:00
|
|
|
snprintf(fetch_cmd, sizeof(fetch_cmd),
|
|
|
|
"FETCH FORWARD %d FROM _psql_cursor",
|
2013-02-02 23:06:38 +01:00
|
|
|
fetch_count);
|
2006-08-30 00:25:08 +02:00
|
|
|
|
|
|
|
/* prepare to write output to \g argument, if any */
|
|
|
|
if (pset.gfname)
|
|
|
|
{
|
2015-12-03 20:28:58 +01:00
|
|
|
if (!openQueryOutputFile(pset.gfname, &fout, &is_pipe))
|
2006-08-30 00:25:08 +02:00
|
|
|
{
|
|
|
|
OK = false;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2015-12-03 20:28:58 +01:00
|
|
|
if (is_pipe)
|
|
|
|
disable_sigpipe_trap();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
fout = pset.queryFout;
|
|
|
|
is_pipe = false; /* doesn't matter */
|
2006-08-30 00:25:08 +02:00
|
|
|
}
|
|
|
|
|
2010-05-28 22:02:32 +02:00
|
|
|
/* clear any pre-existing error indication on the output stream */
|
2015-12-03 20:28:58 +01:00
|
|
|
clearerr(fout);
|
2010-05-28 22:02:32 +02:00
|
|
|
|
2006-08-30 00:25:08 +02:00
|
|
|
for (;;)
|
|
|
|
{
|
2021-10-12 21:14:50 +02:00
|
|
|
if (timing)
|
2008-05-14 21:10:29 +02:00
|
|
|
INSTR_TIME_SET_CURRENT(before);
|
2006-08-30 00:25:08 +02:00
|
|
|
|
2013-02-02 23:06:38 +01:00
|
|
|
/* get fetch_count tuples at a time */
|
2022-02-10 12:03:35 +01:00
|
|
|
result = PQexec(pset.db, fetch_cmd);
|
2006-08-30 00:25:08 +02:00
|
|
|
|
2021-10-12 21:14:50 +02:00
|
|
|
if (timing)
|
2006-08-30 00:25:08 +02:00
|
|
|
{
|
2008-05-14 21:10:29 +02:00
|
|
|
INSTR_TIME_SET_CURRENT(after);
|
|
|
|
INSTR_TIME_SUBTRACT(after, before);
|
|
|
|
*elapsed_msec += INSTR_TIME_GET_MILLISEC(after);
|
2006-08-30 00:25:08 +02:00
|
|
|
}
|
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
if (PQresultStatus(result) != PGRES_TUPLES_OK)
|
2006-08-30 00:25:08 +02:00
|
|
|
{
|
2006-08-30 00:48:55 +02:00
|
|
|
/* shut down pager before printing error message */
|
2015-12-03 20:28:58 +01:00
|
|
|
if (is_pager)
|
2006-08-30 00:48:55 +02:00
|
|
|
{
|
2015-12-03 20:28:58 +01:00
|
|
|
ClosePager(fout);
|
|
|
|
is_pager = false;
|
2006-08-30 00:48:55 +02:00
|
|
|
}
|
|
|
|
|
2022-04-04 14:57:17 +02:00
|
|
|
OK = AcceptResult(result, true);
|
2012-12-15 00:03:07 +01:00
|
|
|
Assert(!OK);
|
2022-02-10 12:03:35 +01:00
|
|
|
SetResultVariables(result, OK);
|
|
|
|
ClearOrSaveResult(result);
|
2006-08-30 00:25:08 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-02-02 23:06:38 +01:00
|
|
|
if (pset.gset_prefix)
|
|
|
|
{
|
|
|
|
/* StoreQueryTuple will complain if not exactly one row */
|
2022-02-10 12:03:35 +01:00
|
|
|
OK = StoreQueryTuple(result);
|
|
|
|
ClearOrSaveResult(result);
|
2013-02-02 23:06:38 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-09-06 00:17:47 +02:00
|
|
|
/*
|
|
|
|
* Note we do not deal with \gdesc, \gexec or \crosstabview modes here
|
|
|
|
*/
|
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
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
ntuples = PQntuples(result);
|
2017-09-13 01:27:48 +02:00
|
|
|
total_tuples += ntuples;
|
2006-08-30 00:25:08 +02:00
|
|
|
|
2013-02-02 23:06:38 +01:00
|
|
|
if (ntuples < fetch_count)
|
2006-08-30 00:25:08 +02:00
|
|
|
{
|
|
|
|
/* this is the last result set, so allow footer decoration */
|
|
|
|
my_popt.topt.stop_table = true;
|
|
|
|
}
|
2015-12-03 20:28:58 +01:00
|
|
|
else if (fout == stdout && !is_pager)
|
2006-08-30 00:25:08 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If query requires multiple result sets, hack to ensure that
|
|
|
|
* only one pager instance is used for the whole mess
|
|
|
|
*/
|
2015-12-03 20:28:58 +01:00
|
|
|
fout = PageOutput(INT_MAX, &(my_popt.topt));
|
|
|
|
is_pager = true;
|
2006-08-30 00:25:08 +02:00
|
|
|
}
|
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
printQuery(result, &my_popt, fout, is_pager, pset.logfile);
|
2006-08-30 00:25:08 +02:00
|
|
|
|
2022-02-10 12:03:35 +01:00
|
|
|
ClearOrSaveResult(result);
|
2007-06-22 03:09:28 +02:00
|
|
|
|
2006-08-30 00:25:08 +02:00
|
|
|
/* after the first result set, disallow header decoration */
|
|
|
|
my_popt.topt.start_table = false;
|
|
|
|
my_popt.topt.prior_records += ntuples;
|
|
|
|
|
2010-05-28 22:02:32 +02:00
|
|
|
/*
|
|
|
|
* Make sure to flush the output stream, so intermediate results are
|
|
|
|
* visible to the client immediately. We check the results because if
|
|
|
|
* the pager dies/exits/etc, there's no sense throwing more data at
|
|
|
|
* it.
|
|
|
|
*/
|
2015-12-03 20:28:58 +01:00
|
|
|
flush_error = fflush(fout);
|
2006-08-30 00:25:08 +02:00
|
|
|
|
2010-05-28 22:02:32 +02:00
|
|
|
/*
|
|
|
|
* Check if we are at the end, if a cancel was pressed, or if there
|
|
|
|
* were any errors either trying to flush out the results, or more
|
|
|
|
* generally on the output stream at all. If we hit any errors
|
|
|
|
* writing things to the stream, we presume $PAGER has disappeared and
|
|
|
|
* stop bothering to pull down more data.
|
|
|
|
*/
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
if (ntuples < fetch_count || cancel_pressed || flush_error ||
|
2015-12-03 20:28:58 +01:00
|
|
|
ferror(fout))
|
2006-08-30 00:25:08 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pset.gfname)
|
|
|
|
{
|
2015-12-03 20:28:58 +01:00
|
|
|
/* close \g argument file/pipe */
|
|
|
|
if (is_pipe)
|
|
|
|
{
|
2023-04-06 23:33:38 +02:00
|
|
|
SetShellResultVariables(pclose(fout));
|
2015-12-03 20:28:58 +01:00
|
|
|
restore_sigpipe_trap();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
fclose(fout);
|
2006-08-30 00:25:08 +02:00
|
|
|
}
|
2015-12-03 20:28:58 +01:00
|
|
|
else if (is_pager)
|
2006-08-30 00:25:08 +02:00
|
|
|
{
|
2015-12-03 20:28:58 +01:00
|
|
|
/* close transient pager */
|
|
|
|
ClosePager(fout);
|
2006-08-30 00:25:08 +02:00
|
|
|
}
|
|
|
|
|
2017-09-13 01:27:48 +02:00
|
|
|
if (OK)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We don't have a PGresult here, and even if we did it wouldn't have
|
|
|
|
* the right row count, so fake SetResultVariables(). In error cases,
|
|
|
|
* we already set the result variables above.
|
|
|
|
*/
|
|
|
|
char buf[32];
|
|
|
|
|
|
|
|
SetVariable(pset.vars, "ERROR", "false");
|
|
|
|
SetVariable(pset.vars, "SQLSTATE", "00000");
|
|
|
|
snprintf(buf, sizeof(buf), INT64_FORMAT, total_tuples);
|
|
|
|
SetVariable(pset.vars, "ROW_COUNT", buf);
|
|
|
|
}
|
|
|
|
|
2006-08-30 00:25:08 +02:00
|
|
|
cleanup:
|
2021-10-12 21:14:50 +02:00
|
|
|
if (timing)
|
2008-05-14 21:10:29 +02:00
|
|
|
INSTR_TIME_SET_CURRENT(before);
|
2006-08-30 00:25:08 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We try to close the cursor on either success or failure, but on failure
|
|
|
|
* ignore the result (it's probably just a bleat about being in an aborted
|
|
|
|
* transaction)
|
|
|
|
*/
|
2022-02-10 12:03:35 +01:00
|
|
|
result = PQexec(pset.db, "CLOSE _psql_cursor");
|
2006-08-30 00:25:08 +02:00
|
|
|
if (OK)
|
|
|
|
{
|
2022-04-04 14:57:17 +02:00
|
|
|
OK = AcceptResult(result, true) &&
|
2022-02-10 12:03:35 +01:00
|
|
|
(PQresultStatus(result) == PGRES_COMMAND_OK);
|
|
|
|
ClearOrSaveResult(result);
|
2006-08-30 00:25:08 +02:00
|
|
|
}
|
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
|
|
|
else
|
2022-02-10 12:03:35 +01:00
|
|
|
PQclear(result);
|
2006-08-30 00:25:08 +02:00
|
|
|
|
|
|
|
if (started_txn)
|
|
|
|
{
|
2022-02-10 12:03:35 +01:00
|
|
|
result = PQexec(pset.db, OK ? "COMMIT" : "ROLLBACK");
|
2022-04-04 14:57:17 +02:00
|
|
|
OK &= AcceptResult(result, true) &&
|
2022-02-10 12:03:35 +01:00
|
|
|
(PQresultStatus(result) == PGRES_COMMAND_OK);
|
|
|
|
ClearOrSaveResult(result);
|
2006-08-30 00:25:08 +02:00
|
|
|
}
|
|
|
|
|
2021-10-12 21:14:50 +02:00
|
|
|
if (timing)
|
2006-08-30 00:25:08 +02:00
|
|
|
{
|
2008-05-14 21:10:29 +02:00
|
|
|
INSTR_TIME_SET_CURRENT(after);
|
|
|
|
INSTR_TIME_SUBTRACT(after, before);
|
|
|
|
*elapsed_msec += INSTR_TIME_GET_MILLISEC(after);
|
2006-08-30 00:25:08 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2003-06-28 02:12:40 +02:00
|
|
|
/*
|
2004-09-20 20:51:19 +02:00
|
|
|
* Advance the given char pointer over white space and SQL comments.
|
2003-06-28 02:12:40 +02:00
|
|
|
*/
|
2004-09-20 20:51:19 +02:00
|
|
|
static const char *
|
|
|
|
skip_white_space(const char *query)
|
2003-06-28 02:12:40 +02:00
|
|
|
{
|
2004-09-20 20:51:19 +02:00
|
|
|
int cnestlevel = 0; /* slash-star comment nest level */
|
2003-06-28 02:12:40 +02:00
|
|
|
|
|
|
|
while (*query)
|
|
|
|
{
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
int mblen = PQmblenBounded(query, pset.encoding);
|
2004-09-20 20:51:19 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: we assume the encoding is a superset of ASCII, so that for
|
|
|
|
* example "query[0] == '/'" is meaningful. However, we do NOT assume
|
|
|
|
* that the second and subsequent bytes of a multibyte character
|
|
|
|
* couldn't look like ASCII characters; so it is critical to advance
|
|
|
|
* by mblen, not 1, whenever we haven't exactly identified the
|
|
|
|
* character we are skipping over.
|
|
|
|
*/
|
2003-06-28 02:12:40 +02:00
|
|
|
if (isspace((unsigned char) *query))
|
2004-09-20 20:51:19 +02:00
|
|
|
query += mblen;
|
|
|
|
else if (query[0] == '/' && query[1] == '*')
|
2003-06-28 02:12:40 +02:00
|
|
|
{
|
2004-09-20 20:51:19 +02:00
|
|
|
cnestlevel++;
|
2003-06-28 02:12:40 +02:00
|
|
|
query += 2;
|
|
|
|
}
|
2004-09-20 20:51:19 +02:00
|
|
|
else if (cnestlevel > 0 && query[0] == '*' && query[1] == '/')
|
|
|
|
{
|
|
|
|
cnestlevel--;
|
|
|
|
query += 2;
|
|
|
|
}
|
|
|
|
else if (cnestlevel == 0 && query[0] == '-' && query[1] == '-')
|
2003-06-28 02:12:40 +02:00
|
|
|
{
|
|
|
|
query += 2;
|
2005-10-15 04:49:52 +02:00
|
|
|
|
2004-09-20 20:51:19 +02:00
|
|
|
/*
|
|
|
|
* We have to skip to end of line since any slash-star inside the
|
|
|
|
* -- comment does NOT start a slash-star comment.
|
|
|
|
*/
|
2003-06-28 02:12:40 +02:00
|
|
|
while (*query)
|
|
|
|
{
|
2004-09-20 20:51:19 +02:00
|
|
|
if (*query == '\n')
|
2003-06-28 02:12:40 +02:00
|
|
|
{
|
2004-09-20 20:51:19 +02:00
|
|
|
query++;
|
2003-06-28 02:12:40 +02:00
|
|
|
break;
|
|
|
|
}
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
query += PQmblenBounded(query, pset.encoding);
|
2003-06-28 02:12:40 +02:00
|
|
|
}
|
|
|
|
}
|
2004-09-20 20:51:19 +02:00
|
|
|
else if (cnestlevel > 0)
|
|
|
|
query += mblen;
|
2003-06-28 02:12:40 +02:00
|
|
|
else
|
|
|
|
break; /* found first token */
|
|
|
|
}
|
|
|
|
|
2004-09-20 20:51:19 +02:00
|
|
|
return query;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether a command is one of those for which we should NOT start
|
|
|
|
* a new transaction block (ie, send a preceding BEGIN).
|
|
|
|
*
|
|
|
|
* These include the transaction control statements themselves, plus
|
|
|
|
* certain statements that the backend disallows inside transaction blocks.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
command_no_begin(const char *query)
|
|
|
|
{
|
|
|
|
int wordlen;
|
|
|
|
|
2003-06-28 02:12:40 +02:00
|
|
|
/*
|
2004-09-20 20:51:19 +02:00
|
|
|
* First we must advance over any whitespace and comments.
|
|
|
|
*/
|
|
|
|
query = skip_white_space(query);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check word length (since "beginx" is not "begin").
|
2003-06-28 02:12:40 +02:00
|
|
|
*/
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2003-06-28 02:12:40 +02:00
|
|
|
|
2004-09-20 20:51:19 +02:00
|
|
|
/*
|
|
|
|
* Transaction control commands. These should include every keyword that
|
|
|
|
* gives rise to a TransactionStmt in the backend grammar, except for the
|
|
|
|
* savepoint-related commands.
|
|
|
|
*
|
|
|
|
* (We assume that START must be START TRANSACTION, since there is
|
|
|
|
* presently no other "START foo" command.)
|
|
|
|
*/
|
|
|
|
if (wordlen == 5 && pg_strncasecmp(query, "abort", 5) == 0)
|
|
|
|
return true;
|
2004-05-07 02:24:59 +02:00
|
|
|
if (wordlen == 5 && pg_strncasecmp(query, "begin", 5) == 0)
|
2003-06-28 02:12:40 +02:00
|
|
|
return true;
|
2004-09-20 20:51:19 +02:00
|
|
|
if (wordlen == 5 && pg_strncasecmp(query, "start", 5) == 0)
|
|
|
|
return true;
|
2004-05-07 02:24:59 +02:00
|
|
|
if (wordlen == 6 && pg_strncasecmp(query, "commit", 6) == 0)
|
2003-06-28 02:12:40 +02:00
|
|
|
return true;
|
2004-09-20 20:51:19 +02:00
|
|
|
if (wordlen == 3 && pg_strncasecmp(query, "end", 3) == 0)
|
2003-06-28 02:12:40 +02:00
|
|
|
return true;
|
2004-09-20 20:51:19 +02:00
|
|
|
if (wordlen == 8 && pg_strncasecmp(query, "rollback", 8) == 0)
|
2003-06-28 02:12:40 +02:00
|
|
|
return true;
|
2005-06-18 00:32:51 +02:00
|
|
|
if (wordlen == 7 && pg_strncasecmp(query, "prepare", 7) == 0)
|
|
|
|
{
|
|
|
|
/* PREPARE TRANSACTION is a TC command, PREPARE foo is not */
|
|
|
|
query += wordlen;
|
|
|
|
|
|
|
|
query = skip_white_space(query);
|
|
|
|
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2005-06-18 00:32:51 +02:00
|
|
|
|
|
|
|
if (wordlen == 11 && pg_strncasecmp(query, "transaction", 11) == 0)
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
2004-09-20 20:51:19 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Commands not allowed within transactions. The statements checked for
|
2018-02-17 02:44:15 +01:00
|
|
|
* here should be exactly those that call PreventInTransactionBlock() in
|
2004-09-20 20:51:19 +02:00
|
|
|
* the backend.
|
|
|
|
*/
|
|
|
|
if (wordlen == 6 && pg_strncasecmp(query, "vacuum", 6) == 0)
|
2003-06-28 02:12:40 +02:00
|
|
|
return true;
|
2004-09-20 20:51:19 +02:00
|
|
|
if (wordlen == 7 && pg_strncasecmp(query, "cluster", 7) == 0)
|
2006-08-25 06:06:58 +02:00
|
|
|
{
|
|
|
|
/* CLUSTER with any arguments is allowed in transactions */
|
|
|
|
query += wordlen;
|
|
|
|
|
|
|
|
query = skip_white_space(query);
|
|
|
|
|
|
|
|
if (isalpha((unsigned char) query[0]))
|
|
|
|
return false; /* has additional words */
|
|
|
|
return true; /* it's CLUSTER without arguments */
|
|
|
|
}
|
|
|
|
|
|
|
|
if (wordlen == 6 && pg_strncasecmp(query, "create", 6) == 0)
|
|
|
|
{
|
|
|
|
query += wordlen;
|
|
|
|
|
|
|
|
query = skip_white_space(query);
|
|
|
|
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2006-08-25 06:06:58 +02:00
|
|
|
|
|
|
|
if (wordlen == 8 && pg_strncasecmp(query, "database", 8) == 0)
|
|
|
|
return true;
|
|
|
|
if (wordlen == 10 && pg_strncasecmp(query, "tablespace", 10) == 0)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/* CREATE [UNIQUE] INDEX CONCURRENTLY isn't allowed in xacts */
|
|
|
|
if (wordlen == 6 && pg_strncasecmp(query, "unique", 6) == 0)
|
|
|
|
{
|
|
|
|
query += wordlen;
|
|
|
|
|
|
|
|
query = skip_white_space(query);
|
|
|
|
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2006-08-25 06:06:58 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (wordlen == 5 && pg_strncasecmp(query, "index", 5) == 0)
|
|
|
|
{
|
|
|
|
query += wordlen;
|
|
|
|
|
|
|
|
query = skip_white_space(query);
|
|
|
|
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2006-08-25 06:06:58 +02:00
|
|
|
|
|
|
|
if (wordlen == 12 && pg_strncasecmp(query, "concurrently", 12) == 0)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
2003-06-28 02:12:40 +02:00
|
|
|
|
2014-07-02 05:42:20 +02:00
|
|
|
if (wordlen == 5 && pg_strncasecmp(query, "alter", 5) == 0)
|
|
|
|
{
|
|
|
|
query += wordlen;
|
|
|
|
|
|
|
|
query = skip_white_space(query);
|
|
|
|
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2014-07-02 05:42:20 +02:00
|
|
|
|
|
|
|
/* ALTER SYSTEM isn't allowed in xacts */
|
|
|
|
if (wordlen == 6 && pg_strncasecmp(query, "system", 6) == 0)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2004-09-20 20:51:19 +02:00
|
|
|
/*
|
2006-08-25 06:06:58 +02:00
|
|
|
* Note: these tests will match DROP SYSTEM and REINDEX TABLESPACE, which
|
|
|
|
* aren't really valid commands so we don't care much. The other four
|
|
|
|
* possible matches are correct.
|
2004-09-20 20:51:19 +02:00
|
|
|
*/
|
2006-08-25 06:06:58 +02:00
|
|
|
if ((wordlen == 4 && pg_strncasecmp(query, "drop", 4) == 0) ||
|
2004-09-20 20:51:19 +02:00
|
|
|
(wordlen == 7 && pg_strncasecmp(query, "reindex", 7) == 0))
|
|
|
|
{
|
|
|
|
query += wordlen;
|
|
|
|
|
|
|
|
query = skip_white_space(query);
|
|
|
|
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2004-09-20 20:51:19 +02:00
|
|
|
|
|
|
|
if (wordlen == 8 && pg_strncasecmp(query, "database", 8) == 0)
|
|
|
|
return true;
|
2005-06-22 23:14:31 +02:00
|
|
|
if (wordlen == 6 && pg_strncasecmp(query, "system", 6) == 0)
|
|
|
|
return true;
|
2004-09-20 20:51:19 +02:00
|
|
|
if (wordlen == 10 && pg_strncasecmp(query, "tablespace", 10) == 0)
|
|
|
|
return true;
|
2019-03-29 08:25:20 +01:00
|
|
|
if (wordlen == 5 && (pg_strncasecmp(query, "index", 5) == 0 ||
|
|
|
|
pg_strncasecmp(query, "table", 5) == 0))
|
|
|
|
{
|
|
|
|
query += wordlen;
|
|
|
|
query = skip_white_space(query);
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2019-03-29 08:25:20 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* REINDEX [ TABLE | INDEX ] CONCURRENTLY are not allowed in
|
|
|
|
* xacts.
|
|
|
|
*/
|
|
|
|
if (wordlen == 12 && pg_strncasecmp(query, "concurrently", 12) == 0)
|
|
|
|
return true;
|
|
|
|
}
|
2015-03-20 02:16:42 +01:00
|
|
|
|
|
|
|
/* DROP INDEX CONCURRENTLY isn't allowed in xacts */
|
|
|
|
if (wordlen == 5 && pg_strncasecmp(query, "index", 5) == 0)
|
|
|
|
{
|
|
|
|
query += wordlen;
|
|
|
|
|
|
|
|
query = skip_white_space(query);
|
|
|
|
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2015-03-20 02:16:42 +01:00
|
|
|
|
|
|
|
if (wordlen == 12 && pg_strncasecmp(query, "concurrently", 12) == 0)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2010-09-28 20:47:25 +02:00
|
|
|
return false;
|
2004-09-20 20:51:19 +02:00
|
|
|
}
|
|
|
|
|
2010-09-28 08:55:25 +02:00
|
|
|
/* DISCARD ALL isn't allowed in xacts, but other variants are allowed. */
|
2010-09-28 07:20:17 +02:00
|
|
|
if (wordlen == 7 && pg_strncasecmp(query, "discard", 7) == 0)
|
2010-09-28 08:55:25 +02:00
|
|
|
{
|
|
|
|
query += wordlen;
|
|
|
|
|
|
|
|
query = skip_white_space(query);
|
|
|
|
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2010-09-28 08:55:25 +02:00
|
|
|
|
|
|
|
if (wordlen == 3 && pg_strncasecmp(query, "all", 3) == 0)
|
|
|
|
return true;
|
2010-09-28 20:47:25 +02:00
|
|
|
return false;
|
2010-09-28 08:55:25 +02:00
|
|
|
}
|
2010-09-28 07:20:17 +02:00
|
|
|
|
2003-06-28 02:12:40 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2003-03-20 07:43:35 +01:00
|
|
|
|
2006-08-30 00:25:08 +02:00
|
|
|
/*
|
|
|
|
* Check whether the specified command is a SELECT (or VALUES).
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
is_select_command(const char *query)
|
|
|
|
{
|
|
|
|
int wordlen;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First advance over any whitespace, comments and left parentheses.
|
|
|
|
*/
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
query = skip_white_space(query);
|
|
|
|
if (query[0] == '(')
|
|
|
|
query++;
|
|
|
|
else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check word length (since "selectx" is not "select").
|
|
|
|
*/
|
|
|
|
wordlen = 0;
|
|
|
|
while (isalpha((unsigned char) query[wordlen]))
|
Fix incautious handling of possibly-miscoded strings in client code.
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
2021-06-07 20:15:25 +02:00
|
|
|
wordlen += PQmblenBounded(&query[wordlen], pset.encoding);
|
2006-08-30 00:25:08 +02:00
|
|
|
|
|
|
|
if (wordlen == 6 && pg_strncasecmp(query, "select", 6) == 0)
|
|
|
|
return true;
|
2006-10-04 02:30:14 +02:00
|
|
|
|
2006-08-30 00:25:08 +02:00
|
|
|
if (wordlen == 6 && pg_strncasecmp(query, "values", 6) == 0)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2003-06-28 02:12:40 +02:00
|
|
|
/*
|
|
|
|
* Test if the current user is a database superuser.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
is_superuser(void)
|
|
|
|
{
|
|
|
|
const char *val;
|
|
|
|
|
|
|
|
if (!pset.db)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
val = PQparameterStatus(pset.db, "is_superuser");
|
|
|
|
|
|
|
|
if (val && strcmp(val, "on") == 0)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
2003-09-04 00:05:09 +02:00
|
|
|
|
|
|
|
|
2006-03-06 20:49:20 +01:00
|
|
|
/*
|
|
|
|
* Test if the current session uses standard string literals.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
standard_strings(void)
|
|
|
|
{
|
|
|
|
const char *val;
|
|
|
|
|
|
|
|
if (!pset.db)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
val = PQparameterStatus(pset.db, "standard_conforming_strings");
|
|
|
|
|
|
|
|
if (val && strcmp(val, "on") == 0)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2003-09-04 00:05:09 +02:00
|
|
|
/*
|
|
|
|
* Return the session user of the current connection.
|
|
|
|
*/
|
|
|
|
const char *
|
|
|
|
session_username(void)
|
|
|
|
{
|
|
|
|
const char *val;
|
|
|
|
|
|
|
|
if (!pset.db)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
val = PQparameterStatus(pset.db, "session_authorization");
|
|
|
|
if (val)
|
|
|
|
return val;
|
|
|
|
else
|
|
|
|
return PQuser(pset.db);
|
|
|
|
}
|
2004-01-09 22:12:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
/* expand_tilde
|
|
|
|
*
|
|
|
|
* substitute '~' with HOME or '~username' with username's home dir
|
|
|
|
*
|
|
|
|
*/
|
2013-04-04 18:56:21 +02:00
|
|
|
void
|
2004-01-09 22:12:20 +01:00
|
|
|
expand_tilde(char **filename)
|
|
|
|
{
|
|
|
|
if (!filename || !(*filename))
|
2013-04-04 18:56:21 +02:00
|
|
|
return;
|
2004-01-09 22:12:20 +01:00
|
|
|
|
2005-06-10 16:49:31 +02:00
|
|
|
/*
|
|
|
|
* WIN32 doesn't use tilde expansion for file names. Also, it uses tilde
|
|
|
|
* for short versions of long file names, though the tilde is usually
|
|
|
|
* toward the end, not at the beginning.
|
|
|
|
*/
|
2004-01-09 22:12:20 +01:00
|
|
|
#ifndef WIN32
|
|
|
|
|
|
|
|
/* try tilde expansion */
|
|
|
|
if (**filename == '~')
|
|
|
|
{
|
|
|
|
char *fn;
|
|
|
|
char oldp,
|
|
|
|
*p;
|
|
|
|
struct passwd *pw;
|
2004-08-18 04:59:12 +02:00
|
|
|
char home[MAXPGPATH];
|
2004-01-09 22:12:20 +01:00
|
|
|
|
|
|
|
fn = *filename;
|
2004-08-18 04:59:12 +02:00
|
|
|
*home = '\0';
|
2004-01-09 22:12:20 +01:00
|
|
|
|
|
|
|
p = fn + 1;
|
|
|
|
while (*p != '/' && *p != '\0')
|
|
|
|
p++;
|
|
|
|
|
|
|
|
oldp = *p;
|
|
|
|
*p = '\0';
|
|
|
|
|
|
|
|
if (*(fn + 1) == '\0')
|
2005-06-10 16:41:32 +02:00
|
|
|
get_home_path(home); /* ~ or ~/ only */
|
2004-01-09 22:12:20 +01:00
|
|
|
else if ((pw = getpwnam(fn + 1)) != NULL)
|
2007-02-08 12:10:27 +01:00
|
|
|
strlcpy(home, pw->pw_dir, sizeof(home)); /* ~user */
|
2004-01-09 22:12:20 +01:00
|
|
|
|
|
|
|
*p = oldp;
|
2004-08-18 04:59:12 +02:00
|
|
|
if (strlen(home) != 0)
|
2004-01-09 22:12:20 +01:00
|
|
|
{
|
|
|
|
char *newfn;
|
|
|
|
|
2013-10-23 01:40:26 +02:00
|
|
|
newfn = psprintf("%s%s", home, p);
|
2004-01-09 22:12:20 +01:00
|
|
|
free(fn);
|
|
|
|
*filename = newfn;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* Checks if connection string starts with either of the valid URI prefix
|
|
|
|
* designators.
|
|
|
|
*
|
|
|
|
* Returns the URI prefix length, 0 if the string doesn't contain a URI prefix.
|
|
|
|
*
|
|
|
|
* XXX This is a duplicate of the eponymous libpq function.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
uri_prefix_length(const char *connstr)
|
|
|
|
{
|
|
|
|
/* The connection URI must start with either of the following designators: */
|
|
|
|
static const char uri_designator[] = "postgresql://";
|
|
|
|
static const char short_uri_designator[] = "postgres://";
|
|
|
|
|
|
|
|
if (strncmp(connstr, uri_designator,
|
|
|
|
sizeof(uri_designator) - 1) == 0)
|
|
|
|
return sizeof(uri_designator) - 1;
|
|
|
|
|
|
|
|
if (strncmp(connstr, short_uri_designator,
|
|
|
|
sizeof(short_uri_designator) - 1) == 0)
|
|
|
|
return sizeof(short_uri_designator) - 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Recognized connection string either starts with a valid URI prefix or
|
|
|
|
* contains a "=" in it.
|
|
|
|
*
|
|
|
|
* Must be consistent with parse_connection_string: anything for which this
|
|
|
|
* returns true should at least look like it's parseable by that routine.
|
|
|
|
*
|
|
|
|
* XXX This is a duplicate of the eponymous libpq function.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
recognized_connection_string(const char *connstr)
|
|
|
|
{
|
|
|
|
return uri_prefix_length(connstr) != 0 || strchr(connstr, '=') != NULL;
|
|
|
|
}
|