psql \watch versus \timing
I'd like to run same query repeatedly and see how long it takes each time.
I thought \watch would be excellent for this, but it turns out that using
\watch suppresses the output of \timing.
Is this intentional, or unavoidable?
Also, is it just or does the inability to watch more frequently than once a
second make it a lot less useful than it could be?
Cheers,
Jeff
Jeff Janes <jeff.janes@gmail.com> writes:
I'd like to run same query repeatedly and see how long it takes each time.
I thought \watch would be excellent for this, but it turns out that using
\watch suppresses the output of \timing.
Is this intentional, or unavoidable?
\watch uses PSQLexec not SendQuery; the latter implements \timing which
I agree is arguably useful here, but also autocommit/auto-savepoint
behavior which probably isn't a good idea.
It might be a good idea to refactor those two routines into one routine
with some sort of bitmap flags argument to control the various add-on
behaviors, but that seems like not 9.3 material anymore.
Also, is it just or does the inability to watch more frequently than once a
second make it a lot less useful than it could be?
It did not seem that exciting to me. In particular, we've already found
out that \watch with zero delay is a pretty bad idea, so you'd have to
make a case for what smaller minimum to use if it's not to be 1 second.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 20, 2013 at 7:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jeff Janes <jeff.janes@gmail.com> writes:
I'd like to run same query repeatedly and see how long it takes each time.
I thought \watch would be excellent for this, but it turns out that using
\watch suppresses the output of \timing.Is this intentional, or unavoidable?
\watch uses PSQLexec not SendQuery; the latter implements \timing which
I agree is arguably useful here, but also autocommit/auto-savepoint
behavior which probably isn't a good idea.It might be a good idea to refactor those two routines into one routine
with some sort of bitmap flags argument to control the various add-on
behaviors, but that seems like not 9.3 material anymore.
Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.
I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.
BTW, I found that \watch doesn't check for async notifications. Is it useful
to allow \watch to do that? ISTM that it's not so bad idea to use \timing
to continuously check for async notifications. No?
Regards,
--
Fujii Masao
Attachments:
enable_timing_in_watch_v1.patchtext/x-patch; charset=US-ASCII; name=enable_timing_in_watch_v1.patchDownload
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
***************
*** 2690,2695 **** do_watch(PQExpBuffer query_buf, long sleep)
--- 2690,2696 ----
PGresult *res;
time_t timer;
long i;
+ double elapsed_msec = 0;
/*
* Prepare title for output. XXX would it be better to use the time
***************
*** 2701,2710 **** do_watch(PQExpBuffer query_buf, long sleep)
myopt.title = title;
/*
! * Run the query. We use PSQLexec, which is kind of cheating, but
! * SendQuery doesn't let us suppress autocommit behavior.
*/
! res = PSQLexec(query_buf->data, false);
/* PSQLexec handles failure results and returns NULL */
if (res == NULL)
--- 2702,2711 ----
myopt.title = title;
/*
! * Run the query. We use PSQLexecInternal, which is kind of cheating,
! * but SendQuery doesn't let us suppress autocommit behavior.
*/
! res = PSQLexecInternal(query_buf->data, false, &elapsed_msec);
/* PSQLexec handles failure results and returns NULL */
if (res == NULL)
***************
*** 2755,2760 **** do_watch(PQExpBuffer query_buf, long sleep)
--- 2756,2765 ----
fflush(pset.queryFout);
+ /* Possible microtiming output */
+ if (pset.timing)
+ printf(_("Time: %.3f ms\n"), elapsed_msec);
+
/*
* Set up cancellation of 'watch' via SIGINT. We redo this each time
* through the loop since it's conceivable something inside PSQLexec
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
***************
*** 439,445 **** AcceptResult(const PGresult *result)
--- 439,459 ----
PGresult *
PSQLexec(const char *query, bool start_xact)
{
+ return PSQLexecInternal(query, start_xact, NULL);
+ }
+
+ /*
+ * Send "backdoor" queries.
+ *
+ * Measure how long the given query takes if elapsed_msec is not NULL and
+ * \timing is enabled.
+ */
+ PGresult *
+ PSQLexecInternal(const char *query, bool start_xact, double *elapsed_msec)
+ {
PGresult *res;
+ instr_time before;
+ instr_time after;
if (!pset.db)
{
***************
*** 483,488 **** PSQLexec(const char *query, bool start_xact)
--- 497,505 ----
PQclear(res);
}
+ if (elapsed_msec != NULL && pset.timing)
+ INSTR_TIME_SET_CURRENT(before);
+
res = PQexec(pset.db, query);
ResetCancelConn();
***************
*** 493,498 **** PSQLexec(const char *query, bool start_xact)
--- 510,522 ----
res = NULL;
}
+ if (elapsed_msec != NULL && pset.timing)
+ {
+ INSTR_TIME_SET_CURRENT(after);
+ INSTR_TIME_SUBTRACT(after, before);
+ *elapsed_msec = INSTR_TIME_GET_MILLISEC(after);
+ }
+
return res;
}
*** a/src/bin/psql/common.h
--- b/src/bin/psql/common.h
***************
*** 37,42 **** extern void SetCancelConn(void);
--- 37,44 ----
extern void ResetCancelConn(void);
extern PGresult *PSQLexec(const char *query, bool start_xact);
+ extern PGresult *PSQLexecInternal(const char *query, bool start_xact,
+ double *elapsed_msec);
extern bool SendQuery(const char *query);
On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.
The patch applies correctly and it does correctly what it is made for:
=# \timing
Timing is on.
=# select 1;
?column?
----------
1
(1 row)
Time: 0.407 ms
=# \watch 1
Watch every 1s Mon Aug 18 15:17:41 2014
?column?
----------
1
(1 row)
Time: 0.397 ms
Watch every 1s Mon Aug 18 15:17:42 2014
?column?
----------
1
(1 row)
Time: 0.615 ms
Refactoring it would be worth it thinking long-term... And printing
the timing in PSQLexec code path is already done in SendQuery, so
that's doing two times the same thing IMHO.
Now, looking at the patch, introducing the new function
PSQLexecInternal with an additional parameter to control the timing is
correct choosing the non-refactoring way of doing. But I don't think
that printing the time outside PSQLexecInternal is consistent with
SendQuery. Why not simply control the timing with a boolean flag and
print the timing directly in PSQLexecInternal?
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.The patch applies correctly and it does correctly what it is made for:
=# \timing
Timing is on.
=# select 1;
?column?
----------
1
(1 row)
Time: 0.407 ms
=# \watch 1
Watch every 1s Mon Aug 18 15:17:41 2014
?column?
----------
1
(1 row)
Time: 0.397 ms
Watch every 1s Mon Aug 18 15:17:42 2014
?column?
----------
1
(1 row)
Time: 0.615 msRefactoring it would be worth it thinking long-term... And printing
the timing in PSQLexec code path is already done in SendQuery, so
that's doing two times the same thing IMHO.Now, looking at the patch, introducing the new function
PSQLexecInternal with an additional parameter to control the timing is
correct choosing the non-refactoring way of doing. But I don't think
that printing the time outside PSQLexecInternal is consistent with
SendQuery. Why not simply control the timing with a boolean flag and
print the timing directly in PSQLexecInternal?
Because the timing needs to be printed after the query result.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 18, 2014 at 4:12 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.The patch applies correctly and it does correctly what it is made for:
=# \timing
Timing is on.
=# select 1;
?column?
----------
1
(1 row)
Time: 0.407 ms
=# \watch 1
Watch every 1s Mon Aug 18 15:17:41 2014
?column?
----------
1
(1 row)
Time: 0.397 ms
Watch every 1s Mon Aug 18 15:17:42 2014
?column?
----------
1
(1 row)
Time: 0.615 msRefactoring it would be worth it thinking long-term... And printing
the timing in PSQLexec code path is already done in SendQuery, so
that's doing two times the same thing IMHO.Now, looking at the patch, introducing the new function
PSQLexecInternal with an additional parameter to control the timing is
correct choosing the non-refactoring way of doing. But I don't think
that printing the time outside PSQLexecInternal is consistent with
SendQuery. Why not simply control the timing with a boolean flag and
print the timing directly in PSQLexecInternal?Because the timing needs to be printed after the query result.
Thanks for pointing that. Yes this makes the refactoring a bit more difficult.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/18/2014 10:51 AM, Michael Paquier wrote:
On Mon, Aug 18, 2014 at 4:12 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.The patch applies correctly and it does correctly what it is made for:
=# \timing
Timing is on.
=# select 1;
?column?
----------
1
(1 row)
Time: 0.407 ms
=# \watch 1
Watch every 1s Mon Aug 18 15:17:41 2014
?column?
----------
1
(1 row)
Time: 0.397 ms
Watch every 1s Mon Aug 18 15:17:42 2014
?column?
----------
1
(1 row)
Time: 0.615 msRefactoring it would be worth it thinking long-term... And printing
the timing in PSQLexec code path is already done in SendQuery, so
that's doing two times the same thing IMHO.Now, looking at the patch, introducing the new function
PSQLexecInternal with an additional parameter to control the timing is
correct choosing the non-refactoring way of doing. But I don't think
that printing the time outside PSQLexecInternal is consistent with
SendQuery. Why not simply control the timing with a boolean flag and
print the timing directly in PSQLexecInternal?Because the timing needs to be printed after the query result.
Thanks for pointing that. Yes this makes the refactoring a bit more difficult.
Michael reviewed this, so I'm marking this as Ready for Committer. Since
you're a committer yourself, I expect you'll take it over from here.
I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for
internal commands.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
On 08/18/2014 10:51 AM, Michael Paquier wrote:
On Mon, Aug 18, 2014 at 4:12 PM, Fujii Masao <masao.fujii@gmail.com>
wrote:On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao.fujii@gmail.com>
wrote:Attached patch changes \watch so that it displays how long the query
takes
if \timing is enabled.I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.The patch applies correctly and it does correctly what it is made for:
=# \timing
Timing is on.
=# select 1;
?column?
----------
1
(1 row)
Time: 0.407 ms
=# \watch 1
Watch every 1s Mon Aug 18 15:17:41 2014
?column?
----------
1
(1 row)
Time: 0.397 ms
Watch every 1s Mon Aug 18 15:17:42 2014
?column?
----------
1
(1 row)
Time: 0.615 msRefactoring it would be worth it thinking long-term... And printing
the timing in PSQLexec code path is already done in SendQuery, so
that's doing two times the same thing IMHO.Now, looking at the patch, introducing the new function
PSQLexecInternal with an additional parameter to control the timing is
correct choosing the non-refactoring way of doing. But I don't think
that printing the time outside PSQLexecInternal is consistent with
SendQuery. Why not simply control the timing with a boolean flag and
print the timing directly in PSQLexecInternal?Because the timing needs to be printed after the query result.
Thanks for pointing that. Yes this makes the refactoring a bit more
difficult.Michael reviewed this, so I'm marking this as Ready for Committer. Since
you're a committer yourself, I expect you'll take it over from here.
Yep!
I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for internal
commands.
Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/25/2014 09:22 PM, Fujii Masao wrote:
On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for internal
commands.Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?
Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling. Do we want --echo-hidden to print the \watch'd
query? Not sure..
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
On 08/25/2014 09:22 PM, Fujii Masao wrote:
On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for internal
commands.Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling. Do we want --echo-hidden to print the \watch'd
query? Not sure..
BTW, I just noticed that none of the callers of PSQLexec pass
"start_xact=true". So that part of the function is dead code. We might
want to remove it, and replace with a comment noting that PSQLexec never
starts a new transaction block, even in autocommit-off mode. (I know
you're hacking on this, so I didnn't want to joggle your elbow by doing
it right now)
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
On 08/25/2014 09:22 PM, Fujii Masao wrote:
On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for
internal
commands.Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling.
Agreed. Attached is the revised version of the patch. I implemented
PSQLexecWatch() which sends the query, prints the results and outputs
the query execution time (if \timing is enabled).
This patch was marked as ready for committer, but since I revised
the code very much, I marked this as needs review again.
Do we want --echo-hidden to print the \watch'd
query? Not sure..
Per document, --echo-hidden prints the actual queries generated by
backslash command. But \watch doesn't handle backslash commands.
So I think that PSQLexecWatch doesn't need to handle --echo-hidden.
BTW, I just noticed that none of the callers of PSQLexec pass
"start_xact=true". So that part of the function is dead code. We might want
to remove it, and replace with a comment noting that PSQLexec never starts a
new transaction block, even in autocommit-off mode. (I know you're hacking
on this, so I didnn't want to joggle your elbow by doing it right now)
Good catch. So I will remove start_xact code later.
Regards,
--
Fujii Masao
Attachments:
enable_timing_in_watch_v2.patchtext/x-patch; charset=US-ASCII; name=enable_timing_in_watch_v2.patchDownload
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
***************
*** 2687,2693 **** do_watch(PQExpBuffer query_buf, long sleep)
for (;;)
{
! PGresult *res;
time_t timer;
long i;
--- 2687,2693 ----
for (;;)
{
! int res;
time_t timer;
long i;
***************
*** 2701,2759 **** do_watch(PQExpBuffer query_buf, long sleep)
myopt.title = title;
/*
! * Run the query. We use PSQLexec, which is kind of cheating, but
! * SendQuery doesn't let us suppress autocommit behavior.
*/
! res = PSQLexec(query_buf->data, false);
!
! /* PSQLexec handles failure results and returns NULL */
! if (res == NULL)
! break;
/*
! * If SIGINT is sent while the query is processing, PSQLexec will
! * consume the interrupt. The user's intention, though, is to cancel
! * the entire watch process, so detect a sent cancellation request and
! * exit in this case.
*/
! if (cancel_pressed)
! {
! PQclear(res);
break;
! }
!
! switch (PQresultStatus(res))
! {
! case PGRES_TUPLES_OK:
! printQuery(res, &myopt, pset.queryFout, pset.logfile);
! break;
!
! case PGRES_COMMAND_OK:
! fprintf(pset.queryFout, "%s\n%s\n\n", title, PQcmdStatus(res));
! break;
!
! case PGRES_EMPTY_QUERY:
! psql_error(_("\\watch cannot be used with an empty query\n"));
! PQclear(res);
! return false;
!
! case PGRES_COPY_OUT:
! case PGRES_COPY_IN:
! case PGRES_COPY_BOTH:
! psql_error(_("\\watch cannot be used with COPY\n"));
! PQclear(res);
! return false;
!
! default:
! /* other cases should have been handled by PSQLexec */
! psql_error(_("unexpected result status for \\watch\n"));
! PQclear(res);
! return false;
! }
!
! PQclear(res);
!
! fflush(pset.queryFout);
/*
* Set up cancellation of 'watch' via SIGINT. We redo this each time
--- 2701,2720 ----
myopt.title = title;
/*
! * Run the query and print out the results. We use PSQLexecWatch,
! * which is kind of cheating, but SendQuery doesn't let us suppress
! * autocommit behavior.
*/
! res = PSQLexecWatch(query_buf->data, &myopt);
/*
! * PSQLexecWatch handles the case where we can no longer
! * repeat the query, and returns 0 or -1.
*/
! if (res == 0)
break;
! if (res == -1)
! return false;
/*
* Set up cancellation of 'watch' via SIGINT. We redo this each time
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
***************
*** 497,502 **** PSQLexec(const char *query, bool start_xact)
--- 497,598 ----
}
+ /*
+ * PSQLexecWatch
+ *
+ * This function is used for \watch command to send the query to
+ * the server and print out the results.
+ *
+ * Returns 1 if the query executed successfully, 0 if it cannot be repeated,
+ * e.g., because of the interrupt, -1 on error.
+ */
+ int
+ PSQLexecWatch(const char *query, const printQueryOpt *opt)
+ {
+ PGresult *res;
+ double elapsed_msec = 0;
+ instr_time before;
+ instr_time after;
+
+ if (!pset.db)
+ {
+ psql_error("You are currently not connected to a database.\n");
+ return 0;
+ }
+
+ SetCancelConn();
+
+ if (pset.timing)
+ INSTR_TIME_SET_CURRENT(before);
+
+ res = PQexec(pset.db, query);
+
+ ResetCancelConn();
+
+ if (!AcceptResult(res))
+ {
+ PQclear(res);
+ return 0;
+ }
+
+ if (pset.timing)
+ {
+ INSTR_TIME_SET_CURRENT(after);
+ INSTR_TIME_SUBTRACT(after, before);
+ elapsed_msec = INSTR_TIME_GET_MILLISEC(after);
+ }
+
+ /*
+ * 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.
+ */
+ if (cancel_pressed)
+ {
+ PQclear(res);
+ return 0;
+ }
+
+ switch (PQresultStatus(res))
+ {
+ case PGRES_TUPLES_OK:
+ printQuery(res, opt, pset.queryFout, pset.logfile);
+ break;
+
+ case PGRES_COMMAND_OK:
+ fprintf(pset.queryFout, "%s\n%s\n\n", opt->title, PQcmdStatus(res));
+ break;
+
+ case PGRES_EMPTY_QUERY:
+ psql_error(_("\\watch cannot be used with an empty query\n"));
+ PQclear(res);
+ return -1;
+
+ case PGRES_COPY_OUT:
+ case PGRES_COPY_IN:
+ case PGRES_COPY_BOTH:
+ psql_error(_("\\watch cannot be used with COPY\n"));
+ PQclear(res);
+ return -1;
+
+ default:
+ psql_error(_("unexpected result status for \\watch\n"));
+ PQclear(res);
+ return -1;
+ }
+
+ PQclear(res);
+
+ fflush(pset.queryFout);
+
+ /* Possible microtiming output */
+ if (pset.timing)
+ printf(_("Time: %.3f ms\n"), elapsed_msec);
+
+ return 1;
+ }
+
/*
* PrintNotifications: check for asynchronous notifications, and print them out
*** a/src/bin/psql/common.h
--- b/src/bin/psql/common.h
***************
*** 12,17 ****
--- 12,19 ----
#include <setjmp.h>
#include "libpq-fe.h"
+ #include "print.h"
+
#define atooid(x) ((Oid) strtoul((x), NULL, 10))
extern bool setQFout(const char *fname);
***************
*** 37,42 **** extern void SetCancelConn(void);
--- 39,45 ----
extern void ResetCancelConn(void);
extern PGresult *PSQLexec(const char *query, bool start_xact);
+ extern int PSQLexecWatch(const char *query, const printQueryOpt *opt);
extern bool SendQuery(const char *query);
On 08/28/2014 02:46 PM, Fujii Masao wrote:
On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling.Agreed. Attached is the revised version of the patch. I implemented
PSQLexecWatch() which sends the query, prints the results and outputs
the query execution time (if \timing is enabled).This patch was marked as ready for committer, but since I revised
the code very much, I marked this as needs review again.
This comment:
... We use PSQLexecWatch,
! * which is kind of cheating, but SendQuery doesn't let us suppress
! * autocommit behavior.
is a bit strange now. PSQLexecWatch isn't cheating like reusing PSQLexec
was; it's whole purpose is to run \watch queries.
/*
* Set up cancellation of 'watch' via SIGINT. We redo this each time
* through the loop since it's conceivable something inside PSQLexec
* could change sigint_interrupt_jmp.
*/
This should now say "PSQLexecWatch".
Other than that, looks good to me.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Aug 29, 2014 at 6:33 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
On 08/28/2014 02:46 PM, Fujii Masao wrote:
On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling.Agreed. Attached is the revised version of the patch. I implemented
PSQLexecWatch() which sends the query, prints the results and outputs
the query execution time (if \timing is enabled).This patch was marked as ready for committer, but since I revised
the code very much, I marked this as needs review again.This comment:
... We use PSQLexecWatch,
! * which is kind of cheating, but SendQuery doesn't let us
suppress
! * autocommit behavior.is a bit strange now. PSQLexecWatch isn't cheating like reusing PSQLexec
was; it's whole purpose is to run \watch queries./*
* Set up cancellation of 'watch' via SIGINT. We redo
this each time
* through the loop since it's conceivable something
inside PSQLexec
* could change sigint_interrupt_jmp.
*/This should now say "PSQLexecWatch".
Other than that, looks good to me.
I just tested the patch and this feature works as expected if timing
is on and it displays the individual run time of each query kicked by
\watch. Note that --echo-hidden does not display the query run during
each loop and that this is contrary to the behavior in HEAD so it
breaks backward compatibility, but are there really people relying in
the existing behavior?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
I just tested the patch and this feature works as expected if timing
is on and it displays the individual run time of each query kicked by
\watch. Note that --echo-hidden does not display the query run during
each loop and that this is contrary to the behavior in HEAD so it
breaks backward compatibility, but are there really people relying in
the existing behavior?
ISTM that's an anti-feature anyway, and changing that behavior is a
good thing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Sep 1, 2014 at 11:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
I just tested the patch and this feature works as expected if timing
is on and it displays the individual run time of each query kicked by
\watch. Note that --echo-hidden does not display the query run during
each loop and that this is contrary to the behavior in HEAD so it
breaks backward compatibility, but are there really people relying in
the existing behavior?ISTM that's an anti-feature anyway, and changing that behavior is a
good thing.
OK, then as all the comments are basically addressed, here is an
updated patch correcting the comment problems mentioned by Heikki.
This is ready for a committer.
Regards,
--
Michael
Attachments:
20140903_psql_watch_time.patchtext/x-diff; charset=US-ASCII; name=20140903_psql_watch_time.patchDownload
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
***************
*** 2687,2693 **** do_watch(PQExpBuffer query_buf, long sleep)
for (;;)
{
! PGresult *res;
time_t timer;
long i;
--- 2687,2693 ----
for (;;)
{
! int res;
time_t timer;
long i;
***************
*** 2700,2764 **** do_watch(PQExpBuffer query_buf, long sleep)
sleep, asctime(localtime(&timer)));
myopt.title = title;
! /*
! * Run the query. We use PSQLexec, which is kind of cheating, but
! * SendQuery doesn't let us suppress autocommit behavior.
! */
! res = PSQLexec(query_buf->data, false);
!
! /* PSQLexec handles failure results and returns NULL */
! if (res == NULL)
! break;
/*
! * If SIGINT is sent while the query is processing, PSQLexec will
! * consume the interrupt. The user's intention, though, is to cancel
! * the entire watch process, so detect a sent cancellation request and
! * exit in this case.
*/
! if (cancel_pressed)
! {
! PQclear(res);
break;
! }
!
! switch (PQresultStatus(res))
! {
! case PGRES_TUPLES_OK:
! printQuery(res, &myopt, pset.queryFout, pset.logfile);
! break;
!
! case PGRES_COMMAND_OK:
! fprintf(pset.queryFout, "%s\n%s\n\n", title, PQcmdStatus(res));
! break;
!
! case PGRES_EMPTY_QUERY:
! psql_error(_("\\watch cannot be used with an empty query\n"));
! PQclear(res);
! return false;
!
! case PGRES_COPY_OUT:
! case PGRES_COPY_IN:
! case PGRES_COPY_BOTH:
! psql_error(_("\\watch cannot be used with COPY\n"));
! PQclear(res);
! return false;
!
! default:
! /* other cases should have been handled by PSQLexec */
! psql_error(_("unexpected result status for \\watch\n"));
! PQclear(res);
! return false;
! }
!
! PQclear(res);
!
! fflush(pset.queryFout);
/*
* Set up cancellation of 'watch' via SIGINT. We redo this each time
! * through the loop since it's conceivable something inside PSQLexec
! * could change sigint_interrupt_jmp.
*/
if (sigsetjmp(sigint_interrupt_jmp, 1) != 0)
break;
--- 2700,2721 ----
sleep, asctime(localtime(&timer)));
myopt.title = title;
! /* Run the query and print out the results */
! res = PSQLexecWatch(query_buf->data, &myopt);
/*
! * PSQLexecWatch handles the case where we can no longer
! * repeat the query, and returns 0 or -1.
*/
! if (res == 0)
break;
! if (res == -1)
! return false;
/*
* Set up cancellation of 'watch' via SIGINT. We redo this each time
! * through the loop since it's conceivable something inside
! * PSQLexecWatch could change sigint_interrupt_jmp.
*/
if (sigsetjmp(sigint_interrupt_jmp, 1) != 0)
break;
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
***************
*** 497,502 **** PSQLexec(const char *query, bool start_xact)
--- 497,598 ----
}
+ /*
+ * PSQLexecWatch
+ *
+ * This function is used for \watch command to send the query to
+ * the server and print out the results.
+ *
+ * Returns 1 if the query executed successfully, 0 if it cannot be repeated,
+ * e.g., because of the interrupt, -1 on error.
+ */
+ int
+ PSQLexecWatch(const char *query, const printQueryOpt *opt)
+ {
+ PGresult *res;
+ double elapsed_msec = 0;
+ instr_time before;
+ instr_time after;
+
+ if (!pset.db)
+ {
+ psql_error("You are currently not connected to a database.\n");
+ return 0;
+ }
+
+ SetCancelConn();
+
+ if (pset.timing)
+ INSTR_TIME_SET_CURRENT(before);
+
+ res = PQexec(pset.db, query);
+
+ ResetCancelConn();
+
+ if (!AcceptResult(res))
+ {
+ PQclear(res);
+ return 0;
+ }
+
+ if (pset.timing)
+ {
+ INSTR_TIME_SET_CURRENT(after);
+ INSTR_TIME_SUBTRACT(after, before);
+ elapsed_msec = INSTR_TIME_GET_MILLISEC(after);
+ }
+
+ /*
+ * 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.
+ */
+ if (cancel_pressed)
+ {
+ PQclear(res);
+ return 0;
+ }
+
+ switch (PQresultStatus(res))
+ {
+ case PGRES_TUPLES_OK:
+ printQuery(res, opt, pset.queryFout, pset.logfile);
+ break;
+
+ case PGRES_COMMAND_OK:
+ fprintf(pset.queryFout, "%s\n%s\n\n", opt->title, PQcmdStatus(res));
+ break;
+
+ case PGRES_EMPTY_QUERY:
+ psql_error(_("\\watch cannot be used with an empty query\n"));
+ PQclear(res);
+ return -1;
+
+ case PGRES_COPY_OUT:
+ case PGRES_COPY_IN:
+ case PGRES_COPY_BOTH:
+ psql_error(_("\\watch cannot be used with COPY\n"));
+ PQclear(res);
+ return -1;
+
+ default:
+ psql_error(_("unexpected result status for \\watch\n"));
+ PQclear(res);
+ return -1;
+ }
+
+ PQclear(res);
+
+ fflush(pset.queryFout);
+
+ /* Possible microtiming output */
+ if (pset.timing)
+ printf(_("Time: %.3f ms\n"), elapsed_msec);
+
+ return 1;
+ }
+
/*
* PrintNotifications: check for asynchronous notifications, and print them out
*** a/src/bin/psql/common.h
--- b/src/bin/psql/common.h
***************
*** 12,17 ****
--- 12,19 ----
#include <setjmp.h>
#include "libpq-fe.h"
+ #include "print.h"
+
#define atooid(x) ((Oid) strtoul((x), NULL, 10))
extern bool setQFout(const char *fname);
***************
*** 37,42 **** extern void SetCancelConn(void);
--- 39,45 ----
extern void ResetCancelConn(void);
extern PGresult *PSQLexec(const char *query, bool start_xact);
+ extern int PSQLexecWatch(const char *query, const printQueryOpt *opt);
extern bool SendQuery(const char *query);
On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
OK, then as all the comments are basically addressed, here is an
updated patch correcting the comment problems mentioned by Heikki.
I just tried this and found it doesn't cooperate well with AUTOCOMMIT
= 'off' and ON_ERROR_ROLLBACK = 'on'. Previously \watch would leave
the transaction in a normal state after C-c but now it leaves the
transaction in an aborted state. I assume it previously did a
savepoint around each execution and now it's not doing that at all.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 3, 2014 at 10:56 PM, Greg Stark <stark@mit.edu> wrote:
On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:OK, then as all the comments are basically addressed, here is an
updated patch correcting the comment problems mentioned by Heikki.
Thanks a lot!
I just tried this and found it doesn't cooperate well with AUTOCOMMIT
= 'off' and ON_ERROR_ROLLBACK = 'on'. Previously \watch would leave
the transaction in a normal state after C-c but now it leaves the
transaction in an aborted state. I assume it previously did a
savepoint around each execution and now it's not doing that at all.
No. Previously \watch used PSQLexec and it doesn't use savepoint.
If you enter Ctrl-C while \watch is waiting for the query to end,
\watch would leave the transaction in an aborted state whether
the patch has been applied or not. OTOH, if you enter Ctrl-C while
\watch is sleeping, the transaction remains in normal state.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 3, 2014 at 11:13 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Wed, Sep 3, 2014 at 10:56 PM, Greg Stark <stark@mit.edu> wrote:
On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:OK, then as all the comments are basically addressed, here is an
updated patch correcting the comment problems mentioned by Heikki.Thanks a lot!
Applied. Thanks all!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
On 08/25/2014 09:22 PM, Fujii Masao wrote:
On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for
internal
commands.Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling.Agreed. Attached is the revised version of the patch. I implemented
PSQLexecWatch() which sends the query, prints the results and outputs
the query execution time (if \timing is enabled).This patch was marked as ready for committer, but since I revised
the code very much, I marked this as needs review again.Do we want --echo-hidden to print the \watch'd
query? Not sure..Per document, --echo-hidden prints the actual queries generated by
backslash command. But \watch doesn't handle backslash commands.
So I think that PSQLexecWatch doesn't need to handle --echo-hidden.BTW, I just noticed that none of the callers of PSQLexec pass
"start_xact=true". So that part of the function is dead code. We might want
to remove it, and replace with a comment noting that PSQLexec never starts a
new transaction block, even in autocommit-off mode. (I know you're hacking
on this, so I didnn't want to joggle your elbow by doing it right now)Good catch. So I will remove start_xact code later.
Attached patch removes start_xact from PSQLexec.
Regards,
--
Fujii Masao
Attachments:
remove_start_xact_from_psqlexec_v1.patchtext/x-patch; charset=US-ASCII; name=remove_start_xact_from_psqlexec_v1.patchDownload
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
***************
*** 966,972 **** exec_command(const char *cmd,
printfPQExpBuffer(&buf, "ALTER USER %s PASSWORD ",
fmtId(user));
appendStringLiteralConn(&buf, encrypted_password, pset.db);
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
success = false;
--- 966,972 ----
printfPQExpBuffer(&buf, "ALTER USER %s PASSWORD ",
fmtId(user));
appendStringLiteralConn(&buf, encrypted_password, pset.db);
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
success = false;
***************
*** 2173,2179 **** process_file(char *filename, bool single_txn, bool use_relative_path)
if (single_txn)
{
! if ((res = PSQLexec("BEGIN", false)) == NULL)
{
if (pset.on_error_stop)
{
--- 2173,2179 ----
if (single_txn)
{
! if ((res = PSQLexec("BEGIN")) == NULL)
{
if (pset.on_error_stop)
{
***************
*** 2189,2195 **** process_file(char *filename, bool single_txn, bool use_relative_path)
if (single_txn)
{
! if ((res = PSQLexec("COMMIT", false)) == NULL)
{
if (pset.on_error_stop)
{
--- 2189,2195 ----
if (single_txn)
{
! if ((res = PSQLexec("COMMIT")) == NULL)
{
if (pset.on_error_stop)
{
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
***************
*** 426,435 **** AcceptResult(const PGresult *result)
* This is the way to send "backdoor" queries (those not directly entered
* by the user). It is subject to -E but not -e.
*
- * In autocommit-off mode, a new transaction block is started if start_xact
- * is true; nothing special is done when start_xact is false. Typically,
- * start_xact = false is used for SELECTs and explicit BEGIN/COMMIT commands.
- *
* Caller is responsible for handling the ensuing processing if a COPY
* command is sent.
*
--- 426,431 ----
***************
*** 437,443 **** AcceptResult(const PGresult *result)
* caller uses this path to issue "SET CLIENT_ENCODING".
*/
PGresult *
! PSQLexec(const char *query, bool start_xact)
{
PGresult *res;
--- 433,439 ----
* caller uses this path to issue "SET CLIENT_ENCODING".
*/
PGresult *
! PSQLexec(const char *query)
{
PGresult *res;
***************
*** 468,488 **** PSQLexec(const char *query, bool start_xact)
SetCancelConn();
- if (start_xact &&
- !pset.autocommit &&
- PQtransactionStatus(pset.db) == PQTRANS_IDLE)
- {
- res = PQexec(pset.db, "BEGIN");
- if (PQresultStatus(res) != PGRES_COMMAND_OK)
- {
- psql_error("%s", PQerrorMessage(pset.db));
- PQclear(res);
- ResetCancelConn();
- return NULL;
- }
- PQclear(res);
- }
-
res = PQexec(pset.db, query);
ResetCancelConn();
--- 464,469 ----
*** a/src/bin/psql/common.h
--- b/src/bin/psql/common.h
***************
*** 38,44 **** extern void setup_cancel_handler(void);
extern void SetCancelConn(void);
extern void ResetCancelConn(void);
! extern PGresult *PSQLexec(const char *query, bool start_xact);
extern int PSQLexecWatch(const char *query, const printQueryOpt *opt);
extern bool SendQuery(const char *query);
--- 38,44 ----
extern void SetCancelConn(void);
extern void ResetCancelConn(void);
! extern PGresult *PSQLexec(const char *query);
extern int PSQLexecWatch(const char *query, const printQueryOpt *opt);
extern bool SendQuery(const char *query);
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
***************
*** 114,120 **** describeAggregates(const char *pattern, bool verbose, bool showSystem)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 4;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 114,120 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 4;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 195,201 **** describeTablespaces(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 195,201 ----
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 458,464 **** describeFunctions(const char *functypes, const char *pattern, bool verbose, bool
appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 4;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 458,464 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 4;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 570,576 **** describeTypes(const char *pattern, bool verbose, bool showSystem)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 570,576 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 645,651 **** describeOperators(const char *pattern, bool verbose, bool showSystem)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 3, 4;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 645,651 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 3, 4;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 716,722 **** listAllDbs(const char *pattern, bool verbose)
NULL, "d.datname", NULL, NULL);
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 716,722 ----
NULL, "d.datname", NULL, NULL);
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 796,802 **** permissionsList(const char *pattern)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
if (!res)
{
termPQExpBuffer(&buf);
--- 796,802 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
if (!res)
{
termPQExpBuffer(&buf);
***************
*** 870,876 **** listDefaultACLs(const char *pattern)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 3;");
! res = PSQLexec(buf.data, false);
if (!res)
{
termPQExpBuffer(&buf);
--- 870,876 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 3;");
! res = PSQLexec(buf.data);
if (!res)
{
termPQExpBuffer(&buf);
***************
*** 1046,1052 **** objectDescription(const char *pattern, bool showSystem)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 3;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 1046,1052 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 3;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 1098,1104 **** describeTableDetails(const char *pattern, bool verbose, bool showSystem)
appendPQExpBufferStr(&buf, "ORDER BY 2, 3;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 1098,1104 ----
appendPQExpBufferStr(&buf, "ORDER BY 2, 3;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 1289,1295 **** describeOneTableDetails(const char *schemaname,
oid);
}
! res = PSQLexec(buf.data, false);
if (!res)
goto error_return;
--- 1289,1295 ----
oid);
}
! res = PSQLexec(buf.data);
if (!res)
goto error_return;
***************
*** 1331,1337 **** describeOneTableDetails(const char *schemaname,
/* must be separate because fmtId isn't reentrant */
appendPQExpBuffer(&buf, ".%s;", fmtId(relationname));
! res = PSQLexec(buf.data, false);
if (!res)
goto error_return;
--- 1331,1337 ----
/* must be separate because fmtId isn't reentrant */
appendPQExpBuffer(&buf, ".%s;", fmtId(relationname));
! res = PSQLexec(buf.data);
if (!res)
goto error_return;
***************
*** 1391,1397 **** describeOneTableDetails(const char *schemaname,
appendPQExpBuffer(&buf, "\nWHERE a.attrelid = '%s' AND a.attnum > 0 AND NOT a.attisdropped", oid);
appendPQExpBufferStr(&buf, "\nORDER BY a.attnum;");
! res = PSQLexec(buf.data, false);
if (!res)
goto error_return;
numrows = PQntuples(res);
--- 1391,1397 ----
appendPQExpBuffer(&buf, "\nWHERE a.attrelid = '%s' AND a.attnum > 0 AND NOT a.attisdropped", oid);
appendPQExpBufferStr(&buf, "\nORDER BY a.attnum;");
! res = PSQLexec(buf.data);
if (!res)
goto error_return;
numrows = PQntuples(res);
***************
*** 1505,1511 **** describeOneTableDetails(const char *schemaname,
printfPQExpBuffer(&buf,
"SELECT pg_catalog.pg_get_viewdef('%s'::pg_catalog.oid, true);",
oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
--- 1505,1511 ----
printfPQExpBuffer(&buf,
"SELECT pg_catalog.pg_get_viewdef('%s'::pg_catalog.oid, true);",
oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
***************
*** 1644,1650 **** describeOneTableDetails(const char *schemaname,
"AND i.indrelid = c2.oid;",
oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else if (PQntuples(result) != 1)
--- 1644,1650 ----
"AND i.indrelid = c2.oid;",
oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else if (PQntuples(result) != 1)
***************
*** 1723,1729 **** describeOneTableDetails(const char *schemaname,
"\n AND d.deptype='a'",
oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else if (PQntuples(result) == 1)
--- 1723,1729 ----
"\n AND d.deptype='a'",
oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else if (PQntuples(result) == 1)
***************
*** 1780,1786 **** describeOneTableDetails(const char *schemaname,
"WHERE c.oid = '%s' AND c.oid = i.indrelid AND i.indexrelid = c2.oid\n"
"ORDER BY i.indisprimary DESC, i.indisunique DESC, c2.relname;",
oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else
--- 1780,1786 ----
"WHERE c.oid = '%s' AND c.oid = i.indrelid AND i.indexrelid = c2.oid\n"
"ORDER BY i.indisprimary DESC, i.indisunique DESC, c2.relname;",
oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else
***************
*** 1864,1870 **** describeOneTableDetails(const char *schemaname,
"WHERE r.conrelid = '%s' AND r.contype = 'c'\n"
"ORDER BY 1;",
oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else
--- 1864,1870 ----
"WHERE r.conrelid = '%s' AND r.contype = 'c'\n"
"ORDER BY 1;",
oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else
***************
*** 1895,1901 **** describeOneTableDetails(const char *schemaname,
"FROM pg_catalog.pg_constraint r\n"
"WHERE r.conrelid = '%s' AND r.contype = 'f' ORDER BY 1;",
oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else
--- 1895,1901 ----
"FROM pg_catalog.pg_constraint r\n"
"WHERE r.conrelid = '%s' AND r.contype = 'f' ORDER BY 1;",
oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else
***************
*** 1926,1932 **** describeOneTableDetails(const char *schemaname,
"FROM pg_catalog.pg_constraint c\n"
"WHERE c.confrelid = '%s' AND c.contype = 'f' ORDER BY 1;",
oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else
--- 1926,1932 ----
"FROM pg_catalog.pg_constraint c\n"
"WHERE c.confrelid = '%s' AND c.contype = 'f' ORDER BY 1;",
oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else
***************
*** 1969,1975 **** describeOneTableDetails(const char *schemaname,
"WHERE r.ev_class = '%s' ORDER BY 1;",
oid);
}
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else
--- 1969,1975 ----
"WHERE r.ev_class = '%s' ORDER BY 1;",
oid);
}
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else
***************
*** 2060,2066 **** describeOneTableDetails(const char *schemaname,
"FROM pg_catalog.pg_rewrite r\n"
"WHERE r.ev_class = '%s' AND r.rulename != '_RETURN' ORDER BY 1;",
oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
--- 2060,2066 ----
"FROM pg_catalog.pg_rewrite r\n"
"WHERE r.ev_class = '%s' AND r.rulename != '_RETURN' ORDER BY 1;",
oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
***************
*** 2117,2123 **** describeOneTableDetails(const char *schemaname,
" WHERE d.classid = t.tableoid AND d.objid = t.oid AND d.deptype = 'i' AND c.contype = 'f'))");
appendPQExpBufferStr(&buf, "\nORDER BY 1;");
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else
--- 2117,2123 ----
" WHERE d.classid = t.tableoid AND d.objid = t.oid AND d.deptype = 'i' AND c.contype = 'f'))");
appendPQExpBufferStr(&buf, "\nORDER BY 1;");
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else
***************
*** 2246,2252 **** describeOneTableDetails(const char *schemaname,
" pg_catalog.pg_foreign_server s\n"
"WHERE f.ftrelid = %s AND s.oid = f.ftserver;",
oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else if (PQntuples(result) != 1)
--- 2246,2252 ----
" pg_catalog.pg_foreign_server s\n"
"WHERE f.ftrelid = %s AND s.oid = f.ftserver;",
oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else if (PQntuples(result) != 1)
***************
*** 2273,2279 **** describeOneTableDetails(const char *schemaname,
/* print inherited tables */
printfPQExpBuffer(&buf, "SELECT c.oid::pg_catalog.regclass FROM pg_catalog.pg_class c, pg_catalog.pg_inherits i WHERE c.oid=i.inhparent AND i.inhrelid = '%s' ORDER BY inhseqno;", oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else
--- 2273,2279 ----
/* print inherited tables */
printfPQExpBuffer(&buf, "SELECT c.oid::pg_catalog.regclass FROM pg_catalog.pg_class c, pg_catalog.pg_inherits i WHERE c.oid=i.inhparent AND i.inhrelid = '%s' ORDER BY inhseqno;", oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else
***************
*** 2306,2312 **** describeOneTableDetails(const char *schemaname,
else
printfPQExpBuffer(&buf, "SELECT c.oid::pg_catalog.regclass FROM pg_catalog.pg_class c, pg_catalog.pg_inherits i WHERE c.oid=i.inhrelid AND i.inhparent = '%s' ORDER BY c.relname;", oid);
! result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
else
--- 2306,2312 ----
else
printfPQExpBuffer(&buf, "SELECT c.oid::pg_catalog.regclass FROM pg_catalog.pg_class c, pg_catalog.pg_inherits i WHERE c.oid=i.inhrelid AND i.inhparent = '%s' ORDER BY c.relname;", oid);
! result = PSQLexec(buf.data);
if (!result)
goto error_return;
else
***************
*** 2453,2459 **** add_tablespace_footer(printTableContent *const cont, char relkind,
printfPQExpBuffer(&buf,
"SELECT spcname FROM pg_catalog.pg_tablespace\n"
"WHERE oid = '%u';", tablespace);
! result = PSQLexec(buf.data, false);
if (!result)
return;
/* Should always be the case, but.... */
--- 2453,2459 ----
printfPQExpBuffer(&buf,
"SELECT spcname FROM pg_catalog.pg_tablespace\n"
"WHERE oid = '%u';", tablespace);
! result = PSQLexec(buf.data);
if (!result)
return;
/* Should always be the case, but.... */
***************
*** 2552,2558 **** describeRoles(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data, false);
if (!res)
return false;
--- 2552,2558 ----
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data);
if (!res)
return false;
***************
*** 2683,2689 **** listDbRoleSettings(const char *pattern, const char *pattern2)
return false;
}
! res = PSQLexec(buf.data, false);
if (!res)
return false;
--- 2683,2689 ----
return false;
}
! res = PSQLexec(buf.data);
if (!res)
return false;
***************
*** 2844,2850 **** listTables(const char *tabtypes, const char *pattern, bool verbose, bool showSys
appendPQExpBufferStr(&buf, "ORDER BY 1,2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 2844,2850 ----
appendPQExpBufferStr(&buf, "ORDER BY 1,2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 2931,2937 **** listLanguages(const char *pattern, bool verbose, bool showSystem)
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 2931,2937 ----
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3018,3024 **** listDomains(const char *pattern, bool verbose, bool showSystem)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3018,3024 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3092,3098 **** listConversions(const char *pattern, bool verbose, bool showSystem)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3092,3098 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3158,3164 **** listEventTriggers(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3158,3164 ----
appendPQExpBufferStr(&buf, "ORDER BY 1");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3257,3263 **** listCasts(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, ") )\nORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3257,3263 ----
appendPQExpBufferStr(&buf, ") )\nORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3333,3339 **** listCollations(const char *pattern, bool verbose, bool showSystem)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3333,3339 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3392,3398 **** listSchemas(const char *pattern, bool verbose, bool showSystem)
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3392,3398 ----
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3449,3455 **** listTSParsers(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3449,3455 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3490,3496 **** listTSParsersVerbose(const char *pattern)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3490,3496 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3587,3593 **** describeOneTSParser(const char *oid, const char *nspname, const char *prsname)
gettext_noop("Get token types"),
oid);
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3587,3593 ----
gettext_noop("Get token types"),
oid);
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3619,3625 **** describeOneTSParser(const char *oid, const char *nspname, const char *prsname)
gettext_noop("Description"),
oid);
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3619,3625 ----
gettext_noop("Description"),
oid);
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3695,3701 **** listTSDictionaries(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3695,3701 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3763,3769 **** listTSTemplates(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3763,3769 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3820,3826 **** listTSConfigs(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3820,3826 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3862,3868 **** listTSConfigsVerbose(const char *pattern)
appendPQExpBufferStr(&buf, "ORDER BY 3, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3862,3868 ----
appendPQExpBufferStr(&buf, "ORDER BY 3, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 3940,3946 **** describeOneTSConfig(const char *oid, const char *nspname, const char *cfgname,
gettext_noop("Dictionaries"),
oid);
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 3940,3946 ----
gettext_noop("Dictionaries"),
oid);
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 4041,4047 **** listForeignDataWrappers(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 4041,4047 ----
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 4120,4126 **** listForeignServers(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 4120,4126 ----
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 4178,4184 **** listUserMappings(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 4178,4184 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 4252,4258 **** listForeignTables(const char *pattern, bool verbose)
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 4252,4258 ----
appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 4306,4312 **** listExtensions(const char *pattern)
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 4306,4312 ----
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 4352,4358 **** listExtensionContents(const char *pattern)
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 4352,4358 ----
appendPQExpBufferStr(&buf, "ORDER BY 1;");
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
***************
*** 4412,4418 **** listOneExtensionContents(const char *extname, const char *oid)
gettext_noop("Object Description"),
oid);
! res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
return false;
--- 4412,4418 ----
gettext_noop("Object Description"),
oid);
! res = PSQLexec(buf.data);
termPQExpBuffer(&buf);
if (!res)
return false;
*** a/src/bin/psql/large_obj.c
--- b/src/bin/psql/large_obj.c
***************
*** 73,79 **** start_lo_xact(const char *operation, bool *own_transaction)
{
case PQTRANS_IDLE:
/* need to start our own xact */
! if (!(res = PSQLexec("BEGIN", false)))
return false;
PQclear(res);
*own_transaction = true;
--- 73,79 ----
{
case PQTRANS_IDLE:
/* need to start our own xact */
! if (!(res = PSQLexec("BEGIN")))
return false;
PQclear(res);
*own_transaction = true;
***************
*** 103,111 **** finish_lo_xact(const char *operation, bool own_transaction)
if (own_transaction && pset.autocommit)
{
/* close out our own xact */
! if (!(res = PSQLexec("COMMIT", false)))
{
! res = PSQLexec("ROLLBACK", false);
PQclear(res);
return false;
}
--- 103,111 ----
if (own_transaction && pset.autocommit)
{
/* close out our own xact */
! if (!(res = PSQLexec("COMMIT")))
{
! res = PSQLexec("ROLLBACK");
PQclear(res);
return false;
}
***************
*** 126,132 **** fail_lo_xact(const char *operation, bool own_transaction)
if (own_transaction && pset.autocommit)
{
/* close out our own xact */
! res = PSQLexec("ROLLBACK", false);
PQclear(res);
}
--- 126,132 ----
if (own_transaction && pset.autocommit)
{
/* close out our own xact */
! res = PSQLexec("ROLLBACK");
PQclear(res);
}
***************
*** 209,215 **** do_lo_import(const char *filename_arg, const char *comment_arg)
bufptr += PQescapeStringConn(pset.db, bufptr, comment_arg, slen, NULL);
strcpy(bufptr, "'");
! if (!(res = PSQLexec(cmdbuf, false)))
{
free(cmdbuf);
return fail_lo_xact("\\lo_import", own_transaction);
--- 209,215 ----
bufptr += PQescapeStringConn(pset.db, bufptr, comment_arg, slen, NULL);
strcpy(bufptr, "'");
! if (!(res = PSQLexec(cmdbuf)))
{
free(cmdbuf);
return fail_lo_xact("\\lo_import", own_transaction);
***************
*** 301,307 **** do_lo_list(void)
gettext_noop("Description"));
}
! res = PSQLexec(buf, false);
if (!res)
return false;
--- 301,307 ----
gettext_noop("Description"));
}
! res = PSQLexec(buf);
if (!res)
return false;
On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
Good catch. So I will remove start_xact code later.
Attached patch removes start_xact from PSQLexec.
Nothing negative to say here :)
Patch simply removes the second argument of PSQLexec that was set to
the same value everywhere, aka false as noticed by Heikki. Comments
and code blocks related to this parameter are removed, and the code
compiles, passing check-world as well (just kicked the tests in case).
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 4, 2014 at 10:50:58PM +0900, Michael Paquier wrote:
On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
Good catch. So I will remove start_xact code later.
Attached patch removes start_xact from PSQLexec.
Nothing negative to say here :)
Patch simply removes the second argument of PSQLexec that was set to
the same value everywhere, aka false as noticed by Heikki. Comments
and code blocks related to this parameter are removed, and the code
compiles, passing check-world as well (just kicked the tests in case).
Uh, where are we on this? Should I commit it?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 14, 2014 at 4:49 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Thu, Sep 4, 2014 at 10:50:58PM +0900, Michael Paquier wrote:
On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
Good catch. So I will remove start_xact code later.
Attached patch removes start_xact from PSQLexec.
Nothing negative to say here :)
Patch simply removes the second argument of PSQLexec that was set to
the same value everywhere, aka false as noticed by Heikki. Comments
and code blocks related to this parameter are removed, and the code
compiles, passing check-world as well (just kicked the tests in case).Uh, where are we on this? Should I commit it?
The patch cleaning up the dead code of psql could be clearly applied
now. For the feature itself not sure, it may be better to let
Fujii-san manage it.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 14, 2014 at 8:11 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
On Tue, Oct 14, 2014 at 4:49 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Thu, Sep 4, 2014 at 10:50:58PM +0900, Michael Paquier wrote:
On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
Good catch. So I will remove start_xact code later.
Attached patch removes start_xact from PSQLexec.
Nothing negative to say here :)
Patch simply removes the second argument of PSQLexec that was set to
the same value everywhere, aka false as noticed by Heikki. Comments
and code blocks related to this parameter are removed, and the code
compiles, passing check-world as well (just kicked the tests in case).Uh, where are we on this? Should I commit it?
The patch cleaning up the dead code of psql could be clearly applied
now. For the feature itself not sure, it may be better to let
Fujii-san manage it.
Applied.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers