Basic Q on superfluous primary keys

Consider these two very similar schemas:

Schema 1:

CREATE TABLE foo (
id serial PRIMARY KEY,
frobnitz character(varying 100) NOT NULL UNIQUE
);

CREATE TABLE bar (
id serial PRIMARY KEY,
foo_id int REFERENCES foo(id)
)

Schema 2:

CREATE TABLE foo (
frobnitz character(varying 100) PRIMARY KEY
);

CREATE TABLE bar (
id serial PRIMARY KEY,
frobnitz character(varying 100) REFERENCES foo(frobnitz)
)

The two situations are semantically identical: each record in table bar
refers to a record in table foo. The difference is that in the first
schema, this referencing is done through an "artificial" serial-integer
primary key, while in the second schema this reference is done through a
data field that happens to be unique and not null, so it can serve as
primary key.

I find Schema 1 awkward and unnatural; more specifically, foo.id seems
unnecessary in light of the non-null uniqueness of foo.frobnitz. But I
remember once reading that "long" fields like foo.frobnitz did not make good
primary keys.

Is the field foo.id in Schema 1 superfluous? For example, wouldn't the
referencing from bar to foo really be done "behind the scenes" through some
hidden field (oid?) instead of through the frobnitz text field? Which of
the two schemas would give better perfornance?

Thanks!

kj