Currently we have:

(foreign-error:code foreign-error-object) → alist or #f

Where alist is e.g.:

((number . 2)
  (c-define . errno/ENOENT))

((class-number . 28)
  (class-title . "Invalid Authorization Specification")
  (code . 28P01)
  (condition-name . invalid_password))

Should we splice these alist entries into the top-level alist somehow? A
simple API like this would be convenient and would probably match the
expectations of most users:

(foreign-error:error-set ferr) -> 'errno
(foreign-error:code ferr) -> 2
(foreign-error:symbol ferr) -> 'ENOENT
(foreign-error:message ferr) -> "No such file or directory"

However, it's also nice that we can represent the comprehensive Postgres
example above. It could be split thus:

(foreign-error:error-set ferr) -> 'postgresql
(foreign-error:code ferr) -> '|28P01|
(foreign-error:symbol ferr) -> 'invalid_password
(foreign-error:message ferr) -> "Invalid password"
(foreign-error:class-code ferr) -> 28
(foreign-error:class-title ferr) -> "Invalid Authorization Specification"

It's great that Harold looked into postgres early, since it has
almost-but-not-quite-numeric error codes. If the world were a simpler
place, it would be nice to have a `foreign-error:number` procedure that
returns an integer or #f. But if we used `foreign-error:symbol` for
almost-numeric codes like '|28P01|, where would we stash the
definitely-not-numeric identifiers like 'invalid_password?

A practical solution is to have `foreign-error:code` which can return
either a number or a symbol or #f, as above. Would this be good enough?

The error class seems quite special to postgres; are there many other
interfaces that group their error codes into classes? If there are, then
`foreign-error:class-code` and `foreign-error:class-title` should
probably be first-class (no pun intended :) If not, perhaps they should
go into the free-form alist `foreign-error:data`.

Harold, what do you think?