Re: PQputCopyData dont signal error - Mailing list pgsql-hackers

From Robert Haas
Subject Re: PQputCopyData dont signal error
Date
Msg-id CA+TgmoZNXcQ6wYmk9W_nGJ3RwJwxc2i15jTPqwQ3m00sC7VeVg@mail.gmail.com
Whole thread Raw
In response to Re: PQputCopyData dont signal error  (steve k <steven.c.kohler@nasa.gov>)
Responses Re: PQputCopyData dont signal error
List pgsql-hackers
On Mon, Mar 31, 2014 at 4:21 PM, steve k <steven.c.kohler@nasa.gov> wrote:
> I'd love to see an actual working example where an executing C++ program was
> able to in fact determine that copy data containing bad data that was sent
> by the C++ program was rejected by the server and subsequently the C++
> program was able to raise/log/notify specifically which block of data failed
> and then log information about it.  However, all I ever got was
> PGRES_COMMAND_OK whether or not the data that was sent was rejected as
> containing bad data or not.  Effectively these were silent failures.

With all respect, you're doing someting wrong.  There's plenty of
working C code that does just this, including some I have written.
You made the comment upthread that you found it "amazing that an rdbms
engine as robust as PostGres seems to have this gaping hole in its
capabilities" - and you're right, that would be remarkable.  It would
mean, for example, that users wouldn't be able to know whether their
backups restored OK.  But it turns out that psql and pg_restore can
detect this kind of problem just fine, which means your code should be
able to do the same, if it's written correctly.  So the problem is not
that PostgreSQL doesn't have this capability; it's that you have a bug
in your code.  I can't tell you what the bug is, because I haven't
seen or tried to analyze your code, but I *can* tell you that when
things work for other people and not for you, that's a sign that
you've goofed, not a sign that the feature is missing.

Admittedly, the libpq interface is somewhat confusing, and I often
find it necessary to refer to existing examples of code when trying to
figure out how to do things correctly.  We've been maintaining
backward compatibility for a really long time, and have accumulated a
number of warts along the way, and I'm not sure how much like the
current design things would look if we started over from scratch.  So
if you want to say, hey, this interface is confusing, and it's too
hard to figure out how to use it, I'd have a hard time disagreeing
with that.  But if you want to say, COPY error detection is impossible
under all circumstances because my code for COPY error detection
doesn't work, well, no.  Because psql and other utilities do the same
task just fine using the exact same interfaces.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: psql \d+ and oid display
Next
From: Robert Haas
Date:
Subject: Re: psql \d+ and oid display