Dear Tom,
> > I notice that some tables in pg_catalog have oids, and some do not have
> > them (e.g. pg_attribute, pg_group, pg_shadow...).
>
> That's not a bug, it's a feature. We don't use up OIDs on tables that
> don't need them.
Sure. I did not suggest that this is a bug! I'm sorry if it sounded so.
As I'm playing quite thoroughly with pg_catalog, I bump into every
inconsistency there, "historical and backwards compatibility" stuff as you
named it in a previous mail.
Now as I'm developping (slowly in my free time) some "pg_advisor" queries,
I wish I had some way of referencing objects that I need to designate
(say, an attribute, an index, a table, a constraint, and so on).
So my question still is: Given the fact that I have some use for these
oids, would it make sense to submit a patch to add them? Or if they are
not useful within pg_catalog, then no modification will be accepted for an
"external" tool?
It is sure possible to circumvent the issue by putting the needed
composite keys here and there, but simple plain oids would look better.
One concept/one field looks nicer.
Thanks in advance,
--
Fabien Coelho - coelho@cri.ensmp.fr
