^C in psql (was Re: [HACKERS] Changes in 7.0)

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

In response to

Browse pgsql-hackers by date

  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