Re: [HACKERS] with vs without oids in pg_catalog.*
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 - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] with vs without oids in pg_catalog.*
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] with vs without oids in pg_catalog.*
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 [EMAIL PROTECTED] To: PostgreSQL Patches [EMAIL PROTECTED] Subject: [PATCHES] hint infrastructure setup (v3) Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] with vs without oids in pg_catalog.*
Fabien COELHO [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] with vs without oids in pg_catalog.*
Fabien COELHO [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] with vs without oids in pg_catalog.*
Fabien COELHO [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] with vs without oids in pg_catalog.*
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 - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
