Re: with vs without oids in pg_catalog.*

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: with vs without oids in pg_catalog.*
Дата
Msg-id Pine.LNX.4.58.0403310832280.2084@sablons.cri.ensmp.fr
обсуждение исходный текст
Ответ на Re: with vs without oids in pg_catalog.*  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: with vs without oids in pg_catalog.*  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: logging statement levels
Следующее
От: "Simon Riggs"
Дата:
Сообщение: FW: Increasing security in a shared environment ...