| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Adler <adler(at)glimpser(dot)org> |
| Cc: | Kris Jurka <books(at)ejurka(dot)com>, Dave Cramer <Dave(at)micro-automation(dot)net>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>, Barry Lind <blind(at)xythos(dot)com> |
| Subject: | Re: patch for COPY |
| Date: | 2003-02-09 17:30:06 |
| Message-ID: | 1578.1044811806@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
Michael Adler <adler(at)glimpser(dot)org> writes:
> On Fri, 7 Feb 2003, Kris Jurka wrote:
>>> One of the failings of the copy protocol is that on error basically the
>>> connection is hosed. Is it possible to reset the connection state on
>>> error for the user?
> If we take libpq as the standard for what's practical to acheive with the
> FE/BE protocol, I don't think we'll be able to maintain much. libpq simply
> closes and opens the connection. (following test with a 7.2 installation)
It might be best to just leave this as an open problem until the COPY
protocol is fixed. Making COPY able to recover from errors is one of
the "must fix" items for the next FE/BE protocol revision. There had
been talk of doing this for 7.4, but given the lack of progress so far
I wouldn't want to promise results for 7.4. Maybe 7.5 though. We have
enough accumulated reasons for protocol changes that I think it's
getting to be a high-priority issue.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vernon Wu | 2003-02-09 18:50:28 | Is a right behaviour on inserting a duplicate key? |
| Previous Message | Michael Adler | 2003-02-09 17:08:05 | Re: patch for COPY |