Thread: psql -e
The echo feature of psql echos the query after its executed. does it makes more sense to have the reverse. when we execute an sql batch we are more interested to know the query when psql apparently stops at certain point. regds mallah.
Rajesh Kumar Mallah writes: > The echo feature of psql echos the query after its executed. > does it makes more sense to have the reverse. The query is printed *before* it is executed, but you might not see it because your terminal is not flushing the stdout at the right times. -- Peter Eisentraut peter_e@gmx.net
On Thursday 24 Jul 2003 3:34 pm, Peter Eisentraut wrote: > Rajesh Kumar Mallah writes: > > The echo feature of psql echos the query after its executed. > > does it makes more sense to have the reverse. > > The query is printed *before* it is executed, but you might not see it > because your terminal is not flushing the stdout at the right times. thanks , shud there be a fflush then after that print? or there is something i can do on the shell itself? regds mallah.
Peter Eisentraut <peter_e@gmx.net> writes:
> Rajesh Kumar Mallah writes:
>> The echo feature of psql echos the query after its executed.
>> does it makes more sense to have the reverse.
> The query is printed *before* it is executed, but you might not see it
> because your terminal is not flushing the stdout at the right times.
It might be a good idea to do an explicit fflush(stdout) right after
printing the query. I observe that PSQLexec() does this, and SendQuery
does too in one path --- but not in the other.
regards, tom lane
> > The query is printed *before* it is executed, but you might not see it > > because your terminal is not flushing the stdout at the right times. > > thanks , > shud there be a fflush then after that print? > or there is something i can do on the shell itself? I've been looking into the echo feature, especially as it relates to the \o feature, and there are several places where an fflush would be helpful so that the output appears on a timely basis and always appears in the same order if readline is being used, because readline appears to maintain an independent output buffer. I made the changes for me in 7.3.3 to add some missing fflush's and also changed it so that if echo queries and \o are both on, then the query is echoed to the output file. I can probably create diffs for 7.3.3 if you want them. This was before I got cvs working here, so I have not yet tried these patches in 7.4. I've been holding back in part because of the 7.4 feature freeze period (though that might not be enough of a feature change to raise eyebrows), and also because there appears to be some readline complications. For example, if you try to backspace you can get some weird looking terminal output. The output sections of psql should probably be rewritten to ensure it doesn't intermingle output. It may be desirable to use parallel streams to the console and to an output file (if defined), but that was a bit more than I wanted to bite off as my first project at the time. Tom, would rewriting the output sections interfere with any changes you are/were working on in psql? I probably won't have time to work on this before August 15th at this point, so maybe I should wait until we're ready to start on 7.5 stuff, in which case I may propose several changes in the definitions and options for both the echo and output options in psql. -- Mike Nolan
nolan@celery.tssi.com writes:
> Tom, would rewriting the output sections interfere with any changes
> you are/were working on in psql?
I'm not doing anything with psql ... Peter might be ...
> I probably won't have time to work on
> this before August 15th at this point, so maybe I should wait until we're
> ready to start on 7.5 stuff, in which case I may propose several changes
> in the definitions and options for both the echo and output options
> in psql.
I think throwing in another fflush or two would count as a bug fix.
Anything more extensive probably has to wait for the 7.5 cycle.
regards, tom lane
> I think throwing in another fflush or two would count as a bug fix. > Anything more extensive probably has to wait for the 7.5 cycle. Dealing with readline makes it slightly more complicated than that, because there is an intermingling issue with two independent output streams. In addition to a couple of well-placed fflush's, my hack around the intermingling problem (which apparently only shows up when using the \o option) was to throw a sleep(1) in before it sends the prompt and queries the next line from the terminal, to give things a chance to finish, but I don't know if that is a production-quality fix. (I did find a couple of other examples in the code of a sleep() thrown in apparently to resolve timing issues.) I can take out the code I added to echo the command to the \o stream, since that is a feature that I would probably want to amplify upon anyway. If the team would accept the rest as a bugfix, I can send it. Otherwise, I'll wait for 7.5 and see if I can change the whole output section to eliminate the problem completely. -- Mike Nolan
A macro for the print, which substitutes:
print()
fflush()
for a bare print is a good idea.
And then have a routine that looks for contributions that are mistakenly NOT using the macro.
nolan@celery.tssi.com wrote:
>>>The query is printed *before* it is executed, but you might not see it
>>>because your terminal is not flushing the stdout at the right times.
>>
>>thanks ,
>>shud there be a fflush then after that print?
>>or there is something i can do on the shell itself?
>
>
> I've been looking into the echo feature, especially as it relates
> to the \o feature, and there are several places where an fflush
> would be helpful so that the output appears on a timely basis and always
> appears in the same order if readline is being used, because
> readline appears to maintain an independent output buffer.
>
> I made the changes for me in 7.3.3 to add some missing fflush's and also
> changed it so that if echo queries and \o are both on, then the query
> is echoed to the output file.
>
> I can probably create diffs for 7.3.3 if you want them.
>
> This was before I got cvs working here, so I have not yet tried these
> patches in 7.4. I've been holding back in part because of the 7.4 feature
> freeze period (though that might not be enough of a feature change
> to raise eyebrows), and also because there appears to be some readline
> complications. For example, if you try to backspace you can get some
> weird looking terminal output.
>
> The output sections of psql should probably be rewritten to ensure it
> doesn't intermingle output. It may be desirable to use parallel
> streams to the console and to an output file (if defined), but that was
> a bit more than I wanted to bite off as my first project at the time.
>
> Tom, would rewriting the output sections interfere with any changes
> you are/were working on in psql? I probably won't have time to work on
> this before August 15th at this point, so maybe I should wait until we're
> ready to start on 7.5 stuff, in which case I may propose several changes
> in the definitions and options for both the echo and output options
> in psql.
> --
> Mike Nolan
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
In fact, this kind of development, with a test for all code to see if it is using any unwanted features of the language insteadof inhouse objects, functions, and macros would have saved microsoft's butt a long time ago regarding security issues.Each new group of programmers does the exact same thing the more experienced programmers a usually not doing any more,i.e. buffer overruns, et. al. Dennis Gearon wrote: > A macro for the print, which substitutes: > > print() > fflush() > > for a bare print is a good idea. > > And then have a routine that looks for contributions that are mistakenly > NOT using the macro. > > > nolan@celery.tssi.com wrote: > >>>> The query is printed *before* it is executed, but you might not see it >>>> because your terminal is not flushing the stdout at the right times. >>> >>> >>> thanks , >>> shud there be a fflush then after that print? >>> or there is something i can do on the shell itself? >> >> >> >> I've been looking into the echo feature, especially as it relates >> to the \o feature, and there are several places where an fflush would >> be helpful so that the output appears on a timely basis and always >> appears in the same order if readline is being used, because readline >> appears to maintain an independent output buffer. >> >> I made the changes for me in 7.3.3 to add some missing fflush's and also >> changed it so that if echo queries and \o are both on, then the query >> is echoed to the output file. >> I can probably create diffs for 7.3.3 if you want them. >> >> This was before I got cvs working here, so I have not yet tried these >> patches in 7.4. I've been holding back in part because of the 7.4 >> feature freeze period (though that might not be enough of a feature >> change to raise eyebrows), and also because there appears to be some >> readline complications. For example, if you try to backspace you can >> get some weird looking terminal output. >> The output sections of psql should probably be rewritten to ensure it >> doesn't intermingle output. It may be desirable to use parallel >> streams to the console and to an output file (if defined), but that >> was a bit more than I wanted to bite off as my first project at the time. >> >> Tom, would rewriting the output sections interfere with any changes >> you are/were working on in psql? I probably won't have time to work >> on this before August 15th at this point, so maybe I should wait until >> we're >> ready to start on 7.5 stuff, in which case I may propose several changes >> in the definitions and options for both the echo and output options >> in psql. -- >> Mike Nolan >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >> >
> > A macro for the print, which substitutes: > > print() > fflush() > > for a bare print is a good idea. In addition to print(), fputs() is also used in several places. Most of the \ commands appear to have their own formatting sections, so changing them to use a macro or possibly a function would be desirable, and a function would make separating terminal and \o output into independent streams easier. It may get even more complicated when considering laTex and HTML output. As long as features are on the table, would there be any interest in having an option to output in XML? (This may raise a number of XML design questions, though, and I'm just starting to read 'XML in a Nutshell'.) -- Mike Nolan
Hmm, a little late here, but why not just unbuffer stdout, or are there reasons to preserve some buffering? On Thu, Jul 24, 2003 at 09:53:38AM -0400, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Rajesh Kumar Mallah writes: > >> The echo feature of psql echos the query after its executed. > >> does it makes more sense to have the reverse. > > > The query is printed *before* it is executed, but you might not see it > > because your terminal is not flushing the stdout at the right times. > > It might be a good idea to do an explicit fflush(stdout) right after > printing the query. I observe that PSQLexec() does this, and SendQuery > does too in one path --- but not in the other. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > "All that is needed for the forces of evil to triumph is for enough good > men to do nothing." - Edmond Burke > "The penalty good people pay for not being interested in politics is to be > governed by people worse than themselves." - Plato
Attachment
> Hmm, a little late here, but why not just unbuffer stdout, or are there > reasons to preserve some buffering? Would that resolve the interlaced output issues with readline? -- Mike Nolan
Martijn van Oosterhout <kleptog@svana.org> writes:
> Hmm, a little late here, but why not just unbuffer stdout, or are there
> reasons to preserve some buffering?
Performance. Unbuffered I/O is expensive, and not attractive in situations
where an fflush or two will solve the problem.
regards, tom lane
> nolan@celery.tssi.com writes: > >> Hmm, a little late here, but why not just unbuffer stdout, or are there > >> reasons to preserve some buffering? > > > Would that resolve the interlaced output issues with readline? > > I doubt it, but you could try it to see ... I am more inclined to go with the rewrite of the output sections, which I hope to jump into in mid-August. -- Mike Nolan
nolan@celery.tssi.com writes:
>> Hmm, a little late here, but why not just unbuffer stdout, or are there
>> reasons to preserve some buffering?
> Would that resolve the interlaced output issues with readline?
I doubt it, but you could try it to see ...
regards, tom lane
Hi! I have a doubt, I have somethigs same this... init transaction update from tabla1 set estado=1 where art=0; update from tabla1 set estado=estado+1 where estado=1 final trasaction The second update take the first updates if we are in the same transaction? Tk
I assume this is the fflush you mentioned. Patch attached and applied. --------------------------------------------------------------------------- Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Rajesh Kumar Mallah writes: > >> The echo feature of psql echos the query after its executed. > >> does it makes more sense to have the reverse. > > > The query is printed *before* it is executed, but you might not see it > > because your terminal is not flushing the stdout at the right times. > > It might be a good idea to do an explicit fflush(stdout) right after > printing the query. I observe that PSQLexec() does this, and SendQuery > does too in one path --- but not in the other. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/bin/psql/common.c =================================================================== RCS file: /cvsroot/pgsql-server/src/bin/psql/common.c,v retrieving revision 1.66 diff -c -c -r1.66 common.c *** src/bin/psql/common.c 23 Jul 2003 08:47:39 -0000 1.66 --- src/bin/psql/common.c 31 Jul 2003 04:21:53 -0000 *************** *** 595,602 **** return false; } else if (VariableEquals(pset.vars, "ECHO", "queries")) puts(query); ! SetCancelConn(); if (PQtransactionStatus(pset.db) == PQTRANS_IDLE && --- 595,605 ---- return false; } else if (VariableEquals(pset.vars, "ECHO", "queries")) + { puts(query); ! fflush(stdout); ! } ! SetCancelConn(); if (PQtransactionStatus(pset.db) == PQTRANS_IDLE &&