Re: [HACKERS] psql output locations
On Fri, Aug 17, 2012 at 12:28:58PM -0400, Bruce Momjian wrote: > On Fri, Aug 17, 2012 at 12:22:38PM -0400, Alvaro Herrera wrote: > > Excerpts from Bruce Momjian's message of vie ago 17 11:17:58 -0400 2012: > > > On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote: > > > > On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander > > > > wrote: > > > > >>> * There are a number of things that are always written to stdout, > > > > >>> that > > > > >>> there is no way to redirect. In some cases it's interactive prompts > > > > >>> - > > > > >>> makes sense - but also for example the output of \timing goes to > > > > >>> stdout always. Is there some specific logic behind what/when this > > > > >>> should be done? > > > > >> > > > > >> Everything that is not an error goes to stdout, no? Except the query > > > > >> output, if you change it. > > > > >> > > > > >> Maybe the way to do what you want is to invent a new setting that > > > > >> temporarily changes stdout. > > > > > > > > > > Yeah, that might be it. Or I need separate settings for "put errors in > > > > > the query output stream" and "put non-query-output-but-also-non-errors > > > > > in the query output stream". The effect would be the same, I guess... > > > > > > > > That seems an awful lot harder (and messier) than just changing the > > > > all the call sites to use the same error-reporting function. > > > > > > I have done as you suggested with the attached patch. > > > > The very first hunk in your patch changes code that seems to be > > explicitely checking the "interactive" flag. Is the change really > > wanted there? Note Magnus explicitely commented about those in his > > original post. > > I noticed that but the output would be the same because there is no > input file location to trigger. I thought the interactive flag was > there just to provide more customized text. Applied. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql output locations
On Fri, Aug 17, 2012 at 12:22:38PM -0400, Alvaro Herrera wrote: > Excerpts from Bruce Momjian's message of vie ago 17 11:17:58 -0400 2012: > > On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote: > > > On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander > > > wrote: > > > >>> * There are a number of things that are always written to stdout, that > > > >>> there is no way to redirect. In some cases it's interactive prompts - > > > >>> makes sense - but also for example the output of \timing goes to > > > >>> stdout always. Is there some specific logic behind what/when this > > > >>> should be done? > > > >> > > > >> Everything that is not an error goes to stdout, no? Except the query > > > >> output, if you change it. > > > >> > > > >> Maybe the way to do what you want is to invent a new setting that > > > >> temporarily changes stdout. > > > > > > > > Yeah, that might be it. Or I need separate settings for "put errors in > > > > the query output stream" and "put non-query-output-but-also-non-errors > > > > in the query output stream". The effect would be the same, I guess... > > > > > > That seems an awful lot harder (and messier) than just changing the > > > all the call sites to use the same error-reporting function. > > > > I have done as you suggested with the attached patch. > > The very first hunk in your patch changes code that seems to be > explicitely checking the "interactive" flag. Is the change really > wanted there? Note Magnus explicitely commented about those in his > original post. I noticed that but the output would be the same because there is no input file location to trigger. I thought the interactive flag was there just to provide more customized text. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql output locations
Excerpts from Bruce Momjian's message of vie ago 17 11:17:58 -0400 2012: > On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote: > > On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander > > wrote: > > >>> * There are a number of things that are always written to stdout, that > > >>> there is no way to redirect. In some cases it's interactive prompts - > > >>> makes sense - but also for example the output of \timing goes to > > >>> stdout always. Is there some specific logic behind what/when this > > >>> should be done? > > >> > > >> Everything that is not an error goes to stdout, no? Except the query > > >> output, if you change it. > > >> > > >> Maybe the way to do what you want is to invent a new setting that > > >> temporarily changes stdout. > > > > > > Yeah, that might be it. Or I need separate settings for "put errors in > > > the query output stream" and "put non-query-output-but-also-non-errors > > > in the query output stream". The effect would be the same, I guess... > > > > That seems an awful lot harder (and messier) than just changing the > > all the call sites to use the same error-reporting function. > > I have done as you suggested with the attached patch. The very first hunk in your patch changes code that seems to be explicitely checking the "interactive" flag. Is the change really wanted there? Note Magnus explicitely commented about those in his original post. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql output locations
On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote:
> On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander wrote:
> >>> * There are a number of things that are always written to stdout, that
> >>> there is no way to redirect. In some cases it's interactive prompts -
> >>> makes sense - but also for example the output of \timing goes to
> >>> stdout always. Is there some specific logic behind what/when this
> >>> should be done?
> >>
> >> Everything that is not an error goes to stdout, no? Except the query
> >> output, if you change it.
> >>
> >> Maybe the way to do what you want is to invent a new setting that
> >> temporarily changes stdout.
> >
> > Yeah, that might be it. Or I need separate settings for "put errors in
> > the query output stream" and "put non-query-output-but-also-non-errors
> > in the query output stream". The effect would be the same, I guess...
>
> That seems an awful lot harder (and messier) than just changing the
> all the call sites to use the same error-reporting function.
I have done as you suggested with the attached patch.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
new file mode 100644
index 205bb50..dc04399
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*** HandleSlashCmds(PsqlScanState scan_state
*** 110,116
if (status == PSQL_CMD_UNKNOWN)
{
if (pset.cur_cmd_interactive)
! fprintf(stderr, _("Invalid command \\%s. Try \\? for help.\n"), cmd);
else
psql_error("invalid command \\%s\n", cmd);
status = PSQL_CMD_ERROR;
--- 110,116
if (status == PSQL_CMD_UNKNOWN)
{
if (pset.cur_cmd_interactive)
! psql_error("Invalid command \\%s. Try \\? for help.\n", cmd);
else
psql_error("invalid command \\%s\n", cmd);
status = PSQL_CMD_ERROR;
*** exec_command(const char *cmd,
*** 904,910
if (strcmp(pw1, pw2) != 0)
{
! fprintf(stderr, _("Passwords didn't match.\n"));
success = false;
}
else
--- 904,910
if (strcmp(pw1, pw2) != 0)
{
! psql_error("Passwords didn't match.\n");
success = false;
}
else
*** exec_command(const char *cmd,
*** 922,928
if (!encrypted_password)
{
! fprintf(stderr, _("Password encryption failed.\n"));
success = false;
}
else
--- 922,928
if (!encrypted_password)
{
! psql_error("Password encryption failed.\n");
success = false;
}
else
*** exec_command(const char *cmd,
*** 1441,1447
while ((value = psql_scan_slash_option(scan_state,
OT_NORMAL, NULL, true)))
{
! fprintf(stderr, "+ opt(%d) = |%s|\n", i++, value);
free(value);
}
}
--- 1441,1447
while ((value = psql_scan_slash_option(scan_state,
OT_NORMAL, NULL, true)))
{
! psql_error("+ opt(%d) = |%s|\n", i++, value);
free(value);
}
}
*** do_connect(char *dbname, char *user, cha
*** 1519,1525
* to connect to the wrong database by using defaults, so require
* all parameters to be specified.
*/
! fputs(_("All connection parameters must be supplied because no database connection exists\n"), stderr);
return false;
}
--- 1519,1526
* to connect to the wrong database by using defaults, so require
* all parameters to be specified.
*/
! psql_error("All connection parameters must be supplied because no "
! "database connection exists\n");
return false;
}
*** do_connect(char *dbname, char *user, cha
*** 1608,1614
/* pset.db is left unmodified */
if (o_conn)
! fputs(_("Previous connection kept\n"), stderr);
}
else
{
--- 1609,1615
/* pset.db is left unmodified */
if (o_conn)
! psql_error("Previous connection kept\n");
}
else
{
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
new file mode 100644
index 330d5ce..f5bd0f6
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
*** pg_strdup(const char *string)
*** 42,48
if (!string)
{
! fprintf(stderr, _("%s: pg_strdup: cannot duplicate null pointer (internal error)\n"),
pset.progname);
exit(EXIT_FAILURE);
}
--- 42,48
if (!string)
{
! psql_error("%s: pg_strdup: cannot duplicate null pointer (internal error)\n",
pset.progname);
exit(EXIT_FAILURE);
}
*** psql_error(const char *fmt,...)
*** 161,167
va_list ap;
fflush(stdout);
! if (pset.queryFout != stdout)
fflush(pset.queryFout);
if (pset.inputfile)
--- 161,167
va_list ap;
fflush(stdout);
! if (pset.queryFout && pset.queryFout != stdout)
fflush(pset.queryFout);
if (pset.inputfile)
*** static PGcancel *volati
Re: [HACKERS] psql output locations
On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander wrote: >>> * There are a number of things that are always written to stdout, that >>> there is no way to redirect. In some cases it's interactive prompts - >>> makes sense - but also for example the output of \timing goes to >>> stdout always. Is there some specific logic behind what/when this >>> should be done? >> >> Everything that is not an error goes to stdout, no? Except the query >> output, if you change it. >> >> Maybe the way to do what you want is to invent a new setting that >> temporarily changes stdout. > > Yeah, that might be it. Or I need separate settings for "put errors in > the query output stream" and "put non-query-output-but-also-non-errors > in the query output stream". The effect would be the same, I guess... That seems an awful lot harder (and messier) than just changing the all the call sites to use the same error-reporting function. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql output locations
On Mon, Dec 12, 2011 at 21:04, Peter Eisentraut wrote: > On mån, 2011-12-12 at 14:47 +0100, Magnus Hagander wrote: >> We're either pretty inconsistent with our output in psql, or I'm not >> completely understanding it.. I was trying to implement a switch that >> would let me put all the output in the query output channel controlled >> by \o, and not just the output of the query itself. Because that would >> make it possible to control it from inside the script. Now, this made >> me notice: >> >> * There are 102 calls to psql_error(), 42 direct uses of >> fprintf(stderr), and 7 uses of fputs(stderr). And there is also >> write_stderr() used in the cancel handler. Is there actually a point >> behind all those direct uses, or should they really be psql_error() >> calls? > > Some of this could probably be more more uniform. But I don't see how > this related to your question. All the output goes uniformly to stderr, > which is what matters. I was overriding psql_error() to write it to the same file as the \o output was written too - and that only worked for some of the errors. It seemed like the logical place to put such a redirection... >> * There are a number of things that are always written to stdout, that >> there is no way to redirect. In some cases it's interactive prompts - >> makes sense - but also for example the output of \timing goes to >> stdout always. Is there some specific logic behind what/when this >> should be done? > > Everything that is not an error goes to stdout, no? Except the query > output, if you change it. > > Maybe the way to do what you want is to invent a new setting that > temporarily changes stdout. Yeah, that might be it. Or I need separate settings for "put errors in the query output stream" and "put non-query-output-but-also-non-errors in the query output stream". The effect would be the same, I guess... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql output locations
On mån, 2011-12-12 at 14:47 +0100, Magnus Hagander wrote: > We're either pretty inconsistent with our output in psql, or I'm not > completely understanding it.. I was trying to implement a switch that > would let me put all the output in the query output channel controlled > by \o, and not just the output of the query itself. Because that would > make it possible to control it from inside the script. Now, this made > me notice: > > * There are 102 calls to psql_error(), 42 direct uses of > fprintf(stderr), and 7 uses of fputs(stderr). And there is also > write_stderr() used in the cancel handler. Is there actually a point > behind all those direct uses, or should they really be psql_error() > calls? Some of this could probably be more more uniform. But I don't see how this related to your question. All the output goes uniformly to stderr, which is what matters. > * There are a number of things that are always written to stdout, that > there is no way to redirect. In some cases it's interactive prompts - > makes sense - but also for example the output of \timing goes to > stdout always. Is there some specific logic behind what/when this > should be done? Everything that is not an error goes to stdout, no? Except the query output, if you change it. Maybe the way to do what you want is to invent a new setting that temporarily changes stdout. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] psql output locations
We're either pretty inconsistent with our output in psql, or I'm not completely understanding it.. I was trying to implement a switch that would let me put all the output in the query output channel controlled by \o, and not just the output of the query itself. Because that would make it possible to control it from inside the script. Now, this made me notice: * There are 102 calls to psql_error(), 42 direct uses of fprintf(stderr), and 7 uses of fputs(stderr). And there is also write_stderr() used in the cancel handler. Is there actually a point behind all those direct uses, or should they really be psql_error() calls? * There are a number of things that are always written to stdout, that there is no way to redirect. In some cases it's interactive prompts - makes sense - but also for example the output of \timing goes to stdout always. Is there some specific logic behind what/when this should be done? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
