psql -e

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:

In fact, this kind of development, with a test for all code to see if it is using any unwanted features of the language instead of 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.

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/

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

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

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

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

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