Re: Re: Rough idea for supporting "sequencename.nextval" syntax

"Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> Tom, would it make sense to use this new type in the system tables where
> pg_class oids currently are used, such as pg_attribute.attrelid ?

Probably. We already use regproc where pg_proc OIDs are used --- not
completely consistently IIRC, but it'd be good to be more consistent.

> Then, one could do:
> select attname from pg_attributes where attrelid = 'mytablename';

> If the appropriate type conversions where in place. (I just tried this
> with pg_aggregate, looking for aggregates that use a particular operator,
> and failed, since text(<some regproc>) yields the oid, rather than
> the name.)

Good thought. At the moment an explicit cast is needed for regproc,
and probably the same would be true of regclass unless we did some
further hacking:

regression=# select * from pg_aggregate where aggfinalfn = 'interval_avg';
ERROR: oidin: error in "interval_avg": can't parse "interval_avg"
regression=# select * from pg_aggregate where aggfinalfn = 'interval_avg'::regproc;
aggname | aggowner | aggtransfn | aggfinalfn | aggbasetype | aggtranstype | aggfinaltype | agginitval
---------+----------+----------------+--------------+-------------+--------------+--------------+---------------------
avg | 256 | interval_accum | interval_avg | 1186 | 1187 | 1186 | {0 second,0 second}
(1 row)

I think the reason the literal is resolved as OID not regproc is that we
are using the OID equality operator here (relying on binary equivalence
of OID and regproc). I don't much want to invent a whole set of regproc
and regclass operators to avoid that. Perhaps the unknown-type
resolution rules could be fine-tuned somehow to resolve as the type of
the other operand, rather than the declared input type of the operator,
in cases like this. (Thomas, any thoughts about that?)

Looking at this, I can't help wondering about "regtype" too ...

regards, tom lane