> 1) init_cluster: Which sets up the cluster: init cluster, store node,
> store path and store listen clauses only.
> 2) create_tablekeys: Which creates all "missing" keys: table add key
> clauses only.

I've always thought this feature wasn't a terribly good idea. I
strongly suggest that you alter your db schema manually to include
pkeys as necessary. Using slony generated pkeys causes the following
(minor, but annoying) problems.

1) Adds a column with an awkward name that doesn't otherwise mesh with
the schema. I think that a deliberate design would be better. However
I'm part of the set theory camp ("it is never reasonable to have two
rows which are not distinct from each other"), which no doubt colours
my opinion on this matter.

2) Said column depends on a sequence that is created in the slony
schema, not the same schema as the table. This can be a pain if you
want to do pg_dumps to back up your database and want to exclude the
slony schema for performance reasons.

> And when I inspect the db schema (after running the 1st and 2nd
> script) I see the slony-created key:
>
> CREATE TABLE workflow_type_map
> (
>  "type" varchar(255) NOT NULL DEFAULT ''::character varying,
>  wid int4 NOT NULL DEFAULT 0,
>  "_Slony-I_saime_cluster_rowID" int8 DEFAULT
> nextval('_saime_cluster.sl_rowid_seq'::regclass)
> )
> WITH OIDS;

That's mighty odd. Have you checked to make sure that the slony key
column is correctly called the primary key?