I said:
> Suppose that we invent a new datatype "regclass", similar to regproc:
> it's actually an OID, but it has the additional implication that it is
> the OID of a pg_class row, and the I/O operations for the type try to
> accept or print a class name not just a numeric OID.
> Next, hack the parser to understand that when a function has an argument
> declared as type regclass and is invoked with the syntax relname.func or
> func(relname), what is wanted is for the OID of the relation to be
> passed as a constant argument; the relation is NOT inserted into the
> query's rangetable.
> Then, it's a simple matter to write a variant of nextval that identifies
> its target sequence by OID rather than name.
Actually, there'd be no need to have two versions of nextval().
Consider what happens when you write:
select nextval('foo');
'foo' is an unknown-type literal, so if the only available function
nextval is one that takes "regclass", guess what happens: 'foo' is fed
to the input conversion routine for regclass. Given the above proposal,
the result would be the OID for sequence foo, and away we go.
Interestingly, this'd result in an automatic upgrade path for nextval
calls: an expression like nextval('foo') would be parsed into the same
expression tree as nextval(foo), and with appropriate smarts in
ruleutils.c, it'd get listed that way in your next pg_dump.
There might be some value in continuing to accept "text" input for
nextval, for example to supportselect nextval('tabname' || 'seqname' || '_seq');
which seems like a plausible thing for someone to do. My inclination
would be to handle this by defining a text-to-regclass conversion
function, and still have just one nextval().
This is starting to seem less like a kluge and more like a real
feature...
regards, tom lane