Re: [BUGS] missing foreign key fails silently using COPY - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] missing foreign key fails silently using COPY
Date
Msg-id 9401.1014851049@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] missing foreign key fails silently using COPY  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Greg Copeland
Date:
Subject: Re: single task postgresql
Next
From: Hiroshi Inoue
Date:
Subject: Re: eWeek Poll: Which database is most critical to your