Re: missing foreign key fails silently using COPY

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

In response to

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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