Deleting would-be orphans when creating FK in Postgres
As has been suggested in comments, the standard tool pg_dump might serve you better. It takes a consistent snapshot and preserves referential integrity during backup automatically - given the source DB is consistent (FK constraints in place). Use it if you can!

The related tools pg_dumpall and pg_basebackup have also been mentioned, but those work on whole DB clusters while you obviously only want to copy (parts of) a single database.

However, there may still be valid reasons for the question. It seems unfair to turn it down on speculation. The question itself is interesting enough:

How to import inconsistent data into a FK relationship and fix it?

NOT VALID option

There is no DELETE ANY WOULD-BE ORPHANS option in the creation of FK constraints (like you'd wish), but the related NOT VALID option for FOREIGN KEY constraints in Postgres 9.1 or later should be instrumental. The manual on ALTER TABLE:


ADD table_constraint [ NOT VALID ]

  
  This form adds a new constraint to a table using the same syntax as
  CREATE TABLE, plus the option NOT VALID, which is currently only
  allowed for foreign key and CHECK constraints. If the constraint is
  marked NOT VALID, the potentially-lengthy initial check to verify that
  all rows in the table satisfy the constraint is skipped. The
  constraint will still be enforced against subsequent inserts or
  updates (that is, they'll fail unless there is a matching row in the
  referenced table, in the case of foreign keys; and they'll fail unless
  the new row matches the specified check constraints). But the database
  will not assume that the constraint holds for all rows in the table,
  until it is validated by using the VALIDATE CONSTRAINT option.


So you can create involved tables and import data and create PK constraints, and FK constraints with NOT VALID.

ALTER TABLE child ADD CONSTRAINT child_parent_id_fkey
FOREIGN KEY (parent_id) REFERENCES parent(parent_id) NOT VALID;

That prevents any new writes from violating referential integrity, while tolerating existing violations. (And the system is aware of it.)

Delete orphans later, at the earliest opportunity:

DELETE FROM child c
WHERE  NOT EXISTS (
   SELECT 1 FROM parent p
   WHERE  p.parent_id = c.parent_id
   );


This does nothing if the data is consistent, and the work needs to be done either way to verify integrity. So it won't get any more efficient for unreliable data that needs verification.

Then validate the constraint:

ALTER TABLE child VALIDATE CONSTRAINT child_parent_id_fkey;


Doesn't have to be in the same transaction. Read the manual for details.

Related:


Partial db dump/restore
Disable all constraints and table checks while restoring a dump