From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | ^C in psql (was Re: [HACKERS] Changes in 7.0) |
Date: | 2000-02-26 01:36:00 |
Message-ID: | Pine.LNX.4.21.0002251356420.3063-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane writes:
> For COPY IN, you want to stop sending data lines and send a terminator,
> then PQendcopy() in the usual way.
That's trickier than it sounds. If I simply do a longjmp from the signal
handler and do the clean up at the setjmp destination I have no idea what
the state of the output buffer is. Worse yet, PQputline doesn't seem to
cope so well with longjmps. The second alternative is to set a flag in the
signal handler and have handleCopyIn() check that once in a while. But
that leads to some non-obvious behaviour if I'm entering copy data by
hand, such as ^C only taking effect after I press enter, and/or an extra
zero (default) row being inserted. The way it currently looks I can't
guarantee any consistent state either way. The proper solution would
seemingly be to write separate handlers for interactive and file
input. I'll keep that in mind for next time.
For now I could only offer the hard exit in script mode and letting people
enter their own "\." or ^D in interactive mode (i.e., ignore ^C in that
case).
Meanwhile, ^C during COPY OUT seems back on track.
--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-02-26 01:36:10 | Re: [HACKERS] Cache query implemented |
Previous Message | Don Baccus | 2000-02-26 01:32:05 | Re: [HACKERS] LZTEXT for rule plan stings |