Re: PQputCopyData dont signal error

On Tue, Apr 1, 2014 at 12:14 PM, steve k <steven(dot)c(dot)kohler(at)nasa(dot)gov> wrote:
> I'm already there. Obviously I'm the only one in the room that didn't get
> the memo. I've had some time to reflect on what might be done differently,
> just not any time to try it. If I get it to work I'll let everyone know.
> The code I was working with went away when the Network admins pushed
> something that forced me to reboot and close all my temp file windows last
> Friday. Sorry for any troubles I've caused you all and I didn't mean to put
> everyone on the defensive.

No problem.

> It has occurred to me that I may have been examining the wrong results set.

That definitely seems possible. It is easier than it might be to mess
that up; there's really nothing in the API to warn you if you've made
that mistake. And I've been there myself.

> One of the things you mentioned is "I often find it necessary to refer to
> existing examples of code when trying to figure out how to do things
> correctly". I couldn't agree more. Haven't seen one yet, but found plenty
> of discussion that tap danced around one or more of the components of the
> copy, put, end paradigm. Maybe I should have just asked for a sample code
> snippet but didn't after a day or so of frustration and trying to piece
> together other people's incomplete samples.

FWIW, I've generally found that the best examples are what's in the
core distribution. I'd go and look at a tool like psql or pg_restore
and find the code that handles this, and then copy it and cut it down
to what you need. You could go around looking for other snippets on
the Internet that are more self-contained, but there's too much chance
that they're actually wrong. The code that implements the existing
core tools is more likely to be good code - not that it can never have
any bugs, but it gets a lot of exercise in real-world deployments, so
if something really obvious like error detection is broken then we can
be pretty sure a user will complain.

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