Re: [HACKERS] Changes in 7.0

Here is my list of 7.0 changes. Please let me know of any changes I
should make to it.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

On Wed, 23 Feb 2000, Bruce Momjian wrote:

> Here is my list of 7.0 changes. Please let me know of any changes I
> should make to it.

> Allow ^C to cancel COPY command (Massimo)

That's cool, but if you look closely, psql doesn't do that (anymore). :(
Is it safe to send PQcancelRequest in a copy state and then just forget
about it? What's the correct behaviour? With everyone requesting longjmp's
at the last minute, I had to disable ^C during COPY.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

> On Wed, 23 Feb 2000, Bruce Momjian wrote:
>
> > Here is my list of 7.0 changes. Please let me know of any changes I
> > should make to it.
>
> > Allow ^C to cancel COPY command (Massimo)
>
> That's cool, but if you look closely, psql doesn't do that (anymore). :(
> Is it safe to send PQcancelRequest in a copy state and then just forget
> about it? What's the correct behaviour? With everyone requesting longjmp's
> at the last minute, I had to disable ^C during COPY.

I assume it was during COPY and not \copy.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE> writes:
>> Allow ^C to cancel COPY command (Massimo)

> That's cool, but if you look closely, psql doesn't do that (anymore). :(
> Is it safe to send PQcancelRequest in a copy state and then just forget
> about it? What's the correct behaviour?

For a COPY OUT (from the backend), the correct behavior is same as for
non-copy state: fire off the cancel request and then forget about it.
If the backend decides to honor the request then it will terminate the
copy in the usual way. For a COPY IN, it's up to you to stop sending
data...

regards, tom lane

On Thu, 24 Feb 2000, Tom Lane wrote:

> For a COPY OUT (from the backend), the correct behavior is same as for
> non-copy state: fire off the cancel request and then forget about it.

Do I have to call PQendcopy() is the question.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE> writes:
> On Thu, 24 Feb 2000, Tom Lane wrote:
>> For a COPY OUT (from the backend), the correct behavior is same as for
>> non-copy state: fire off the cancel request and then forget about it.

> Do I have to call PQendcopy() is the question.

Yes, but only after the backend sends the usual copy termination
message. The cancel request doesn't affect the protocol state machine
nor the app's interaction with libpq in the slightest. It's just a side
communication to the backend ("Psst! I'd really appreciate it if we
could wrap this up sooner rather than later.")

For COPY IN, you want to stop sending data lines and send a terminator,
then PQendcopy() in the usual way.

regards, tom lane

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

> Here is my list of 7.0 changes. Please let me know of any changes I
> should make to it.

>New pg_char_to_encoding() and pg_encoding_to_char() functions

done by me.

Also, can you add followings:

New libpq functions PQsetClientEncoding(), PQclientEncoding()
Add support for SJIS user defined characters
Add SQL_ASCII test case to the regression test
--with-mb now deprecated
--
Tatsuo Ishii

Done.

> > Here is my list of 7.0 changes. Please let me know of any changes I
> > should make to it.
>
> >New pg_char_to_encoding() and pg_encoding_to_char() functions
>
> done by me.
>
> Also, can you add followings:
>
> New libpq functions PQsetClientEncoding(), PQclientEncoding()
> Add support for SJIS user defined characters
> Add SQL_ASCII test case to the regression test
> --with-mb now deprecated
> --
> Tatsuo Ishii
>
> ************
>

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026