On Tue, Apr 1, 2014 at 12:14 PM, steve k <steven.c.koh...@nasa.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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers