sequences vs oids as primary keys

i had some questions/thoughts on using sequences vs oids as pks... it's a
common requirement to obtain the last value of a sequence after an insert. most
other databases support such a feature, but since oid's are deprecated, and
only oid's are returned, this isn't supported by postgres (and performance
suffers from having to make an extra sql call).

1) does it make sense (and would it be possible) to make a rule which would,
say, somehow write into the oid field of a tuple to be returned by lastoid? i'm
assuming here that the database would not have oid's enabled.

2) if not, can the C code be modified to support this (maybe ExecInsert())?
basically, if oid's are disabled for a given relation, and a sequence is the
primary key, then instead of returning InvalidOid return the current sequence
value (only for inserting a single row, possibly only if the db has been
configured to support that, etc etc).

3) if not that, would it make sense to enable applications to reserve a pool of
sequence numbers? say, some kind of sequence.reserve(int count) function which
takes the number of id's to reserve and returns the start of the sequence,
where all the sequence #'s in [start, start + count -1] are guaranteed to be
contiguous (or just overload nextval).

4) maybe there's a better way of handling this?

thanks!
--craig

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com