On Wed, 04 Jun 2008, Klint Gore <[EMAIL PROTECTED]> writes:
> postgres=# create table bar (foo int);
> CREATE TABLE
> postgres=# \e
> ERROR: relation "bar" already exists
> postgres=#
Not exactly like that, consider placing a "\c new_copy" line to your
script file.
>> \ef regex - Edit fun
Volkan YAZICI wrote:
2. It would be really neat to be able to issue
\et regex - Edit table. (Create script of table will get dumped.)
\et+ regex - Edit table with dependents. (With create script of
INDEXes, triggers, etc.)
How do you intend to use it?
postgre
Hi,
I have two feature proposals for psql:
1. After executing some set of commands from a file via "\e foo.sql",
pressing C-p or Up brings executed commands, instead of
"\e foo.sql". Shouldn't psql be bringing "\e foo.sql"?
2. It would be really neat to be able to issue
\et regex -
Hello All,
I built the latest postgresql 7.4.2 in HPUX PA.
The command "psql -E ", is not give give the output like in
7.3.4.
In Postgresql 7.3.4, it gives the following output:
$ echo "select * from db5;" | psql -E test
* QUERY **
BEGIN; SELECT usesuper FROM pg_catalog.pg_user
Hello All,
I built the latest postgresql 7.4.2 in HPUX PA.
The command "psql -E ", is not give the
output like in 7.3.4.
In Postgresql 7.3.4, it gives the following output:
$ echo "select * from db5;" | psql -E test
* QUERY **
BEGIN; SELECT usesuper FROM pg_catalog.pg_user WHER
I assume this is the fflush you mentioned. Patch attached and applied.
---
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Rajesh Kumar Mallah writes:
> >> The echo feature of psql echos the query after i
[EMAIL PROTECTED] 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
> [EMAIL PROTECTED] 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
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 th
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.
[EMAIL PROTECTED] wrote:
The query is printed *before* it is executed, but you might
> 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
[EMAIL PROTECTED] 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
> > 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 fe
On Fri, 5 Feb 1999, Bruce Momjian wrote:
> Sounds like an OS bug.
o...k...
Linux is famous for this sort of behaviour, I shoulda guessed.
Anyone else with perhaps a more helpful idea?
Simon.
>
> > Just upgraded to 6.4.2 from 6.3.2 and I've got a bit of a problem.
> >
> > Compiled, inst
Sounds like an OS bug.
> Just upgraded to 6.4.2 from 6.3.2 and I've got a bit of a problem.
>
> Compiled, installed, regressed(?) all went fine. Come to load up the old
> datbases, and it appears that \. is not being recognised as end-of-input
> in the database dump file (I did a pg_dumpall -z,
15 matches
Mail list logo
