Thread: with vs without oids in pg_catalog.*
Dear hackers, I'm still trying to play with pg_catalog relations. I notice that some tables in pg_catalog have oids, and some do not have them (e.g. pg_attribute, pg_group, pg_shadow...). Also convenient user-oriented views could reproduce the oid of their parent table (e.g. pg_user if pg_shadow had an oid). This situation makes referencing such elements a little bit inhomogeneous. Is there a strong backend rational behind these missing features, or would it be possible to suggest some additions in this area? I may imagine some behind the seen updates which could need to be updated, but I cannot seen any major reason why this could not and should not be done... So my question is : would it be reasonnable to submit a new "posgres.bki" version, by dropping some "without_oids" in some declarations?? -- Fabien Coelho - coelho@cri.ensmp.fr
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> 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.
regards, tom lane
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
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> 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).
AFAIK, all objects that you might need to designate can be identified
using the scheme employed in pg_depend and pg_description: catalog OID,
object OID, subobject number.
> 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?
It will be rejected. We removed pg_attribute OIDs some time ago,
and we aren't going to put them back without a much better reason than
this. If you need a specific counterargument, here is one: pg_attribute
is normally much the largest catalog. If we required its rows to have
unique OIDs, the probability of collisions after OID-counter wraparound
would be much greater than it is in other catalogs.
regards, tom lane
Dear Tom, > > 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? > > It will be rejected. That's a simple a direct answer as I like them. So I won't bother to submit a patch;-) BTW, maybe you could reject some of the patches I submitted earlier, rather than to simply ignore them? > We removed pg_attribute OIDs some time ago, and we aren't going to put > them back without a much better reason than this. If you need a > specific counterargument, here is one: pg_attribute is normally much the > largest catalog. If we required its rows to have unique OIDs, the > probability of collisions after OID-counter wraparound would be much > greater than it is in other catalogs. Mmh. Maybe you could have considered sequences. -- Fabien Coelho - coelho@cri.ensmp.fr
Fabien COELHO wrote: > > Dear Tom, > > > > 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? > > > > It will be rejected. > > That's a simple a direct answer as I like them. > So I won't bother to submit a patch;-) > > BTW, maybe you could reject some of the patches I submitted earlier, > rather than to simply ignore them? The only outstanding patch I see from you is: [PATCHES] [NOT] (LIKE|ILIKE) (ANY|SOME|ALL) (subquery...) from March 29. I will put it in the queue now. Are there others we missed? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Dear Bruce, > > BTW, maybe you could reject some of the patches I submitted earlier, > > rather than to simply ignore them? > > The only outstanding patch I see from you is: > > [PATCHES] [NOT] (LIKE|ILIKE) (ANY|SOME|ALL) (subquery...) > > from March 29. I will put it in the queue now. Are there others we > missed? Sure:-) Date: Wed, 17 Mar 2004 09:09:40 +0100 (CET)From: Fabien COELHO <coelho@cri.ensmp.fr>To: PostgreSQL Patches <pgsql-patches@postgresql.org>Subject:[PATCHES] hint infrastructure setup (v3) Have a nice day, -- Fabien Coelho - coelho@cri.ensmp.fr
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> Sure:-)
> Subject: [PATCHES] hint infrastructure setup (v3)
Oh, I was intending to review that but got caught up in functions-
returning-rowtypes hacking. I'll take a look as soon as I'm done
with the rowtypes project (should be in a day or two).
regards, tom lane