From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | missive(at)hotmail(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: missing foreign key fails silently using COPY |
Date: | 2002-02-27 23:04:09 |
Message-ID: | 9401.1014851049@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
I wrote:
> [ In psql, COPY from stdin fails to report referential integrity errors ]
> After further investigation I'm still unsure where to pin the blame.
> What the backend is actually sending back is
> C COPY -- completion tag for COPY
> E errmsg -- error detected during xact completion
> Z -- backend now idle
> which is perfectly reasonable.
After further thought I have decided that the above behavior is probably
not so reasonable after all. PQendcopy essentially assumes that it will
get back *either* an error message or a command-complete message from
a COPY command ... not both. libpq has historically masked similar odd
behavior by looping in PQexec until it gets a 'Z' response, and
returning only the last status. However, applications that use
PQgetResult directly may well assume that they get either a
command-complete or an error per command, not both.
It is fairly simple to tweak the backend so that finish_xact_command is
called before we report command-complete, rather than after; that would
allow end-of-transaction errors to be detected and reported in place of
issuing the command-complete message. I'm now thinking that's the most
reasonable way to resolve this problem. If we insist that it's a client
bug and not a backend misbehavior, we're going to have a lot of clients
to fix.
Any objections?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sidney | 2002-02-27 23:06:31 | Segmentation Fault |
Previous Message | Tom Lane | 2002-02-27 21:41:55 | Re: performance problems on updates on large tables with indexes |
From | Date | Subject | |
---|---|---|---|
Next Message | Mattew T. O'Connor | 2002-02-27 23:35:33 | Re: Oracle vs PostgreSQL in real life |
Previous Message | Greg Copeland | 2002-02-27 23:03:23 | Re: single task postgresql |