> OK, we need to vote on whether Oid's are optional,
> and whether we can have them not created by default.

Optional OIDs:      YES
No OIDs by default: YES

> > > However, OID's keep our system tables together.
> > 
> > How?! If we want to find function with oid X we query
> > pg_proc, if we want to find table with oid Y we query
> > pg_class - we always use oids in context of "class"
> > to what an object belongs. This means that two tuples
> > from different system tables could have same oid values
> > and everything would work perfectly.
> 
> I meant we use them in many cases to link entries, and in
> pg_description for descriptions and lots of other things
> that may use them in the future for system table use.

So, add class' ID (uniq id from pg_class) when linking.

Vadim

Wed, 18 Jul 2001 14:35:06 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: OID wraparound (was Re: pg_depend)
>> I meant we use them in many cases to link entries, and in
>> pg_description for descriptions and lots of other things
>> that may use them in the future for system table use.

pg_description is a point I hadn't thought about --- it uses OIDs
to refer to pg_attribute entries.  However, pg_description is pretty
broken in its assumptions about OIDs anyway.  I'm inclined to change
it to be indexed by

	(object type ID, object OID, attributenumber)

the same way that Philip proposed indexing pg_depend.  Among other
things, that'd make it much cheaper to drop comments during a DROP
TABLE.  You could just scan on (object type ID, object OID), and get
both the table and all its columns in a single indexscan search,
not one per column as happens now.

			regards, tom lane

Wed, 18 Jul 2001 18:26:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: OID wraparound (was Re: pg_depend) 
> >> I meant we use them in many cases to link entries, and in
> >> pg_description for descriptions and lots of other things
> >> that may use them in the future for system table use.
> 
> pg_description is a point I hadn't thought about --- it uses OIDs
> to refer to pg_attribute entries.  However, pg_description is pretty
> broken in its assumptions about OIDs anyway.  I'm inclined to change
> it to be indexed by
> 
> 	(object type ID, object OID, attributenumber)
> 
> the same way that Philip proposed indexing pg_depend.  Among other
> things, that'd make it much cheaper to drop comments during a DROP
> TABLE.  You could just scan on (object type ID, object OID), and get
> both the table and all its columns in a single indexscan search,
> not one per column as happens now.

Remember most pg_description comments are not on column but on functions
and stuff.  That attributenumber is not going to apply there.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 18 Jul 2001 19:47:38 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: OID wraparound (was Re: pg_depend)
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Remember most pg_description comments are not on column but on functions
> and stuff.  That attributenumber is not going to apply there.

Sure, it'd just be zero for non-column items.

			regards, tom lane

Wed, 18 Jul 2001 19:55:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: OID wraparound (was Re: pg_depend) 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Remember most pg_description comments are not on column but on functions
> > and stuff.  That attributenumber is not going to apply there.
> 
> Sure, it'd just be zero for non-column items.

What do we do with other columns that need descriptions and don't have
oid column.  Make the attribute column mean something else?  I just
don't see a huge gain here and lots of confusion.  User tables are a
different story.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 18 Jul 2001 20:00:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: OID wraparound (was Re: pg_depend)
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What do we do with other columns that need descriptions and don't have
> oid column.

Like what?

			regards, tom lane

Wed, 18 Jul 2001 20:43:05 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: OID wraparound (was Re: pg_depend) 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > What do we do with other columns that need descriptions and don't have
> > oid column.
> 
> Like what?

Depends what other system tables you are intending to remove oid's for?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 18 Jul 2001 20:53:29 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: OID wraparound (was Re: pg_depend)
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What do we do with other columns that need descriptions and don't have
> oid column.
>> 
>> Like what?

> Depends what other system tables you are intending to remove oid's for?

Nothing that requires a description ;-)

			regards, tom lane

Wed, 18 Jul 2001 20:58:03 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: OID wraparound (was Re: pg_depend) 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > What do we do with other columns that need descriptions and don't have
> > oid column.
> >> 
> >> Like what?
> 
> > Depends what other system tables you are intending to remove oid's for?
> 
> Nothing that requires a description ;-)

You are a sly one.  :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 18 Jul 2001 20:59:00 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: OID wraparound (was Re: pg_depend)
Tom mentioned what should be stored in the OID system column if no oid's
are in the table.  He also mentioned that he doesn't want a
variable-length tuple header so will always have an oid system column.

What about moving the oid column out of the tuple header.  This saves 4
bytes in the header in cases where there is no oid on the table.

If they ask for an OID in a table, make it the first column of a table. 
Also, if they have asked for oid's on the table, odds are they want
SELECT * to show it.

Also, how about a GUC option that controls whether tables are created
with OID's by default.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 20 Jul 2001 10:20:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: OID wraparound (was Re: pg_depend)
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What about moving the oid column out of the tuple header.  This saves 4
> bytes in the header in cases where there is no oid on the table.

No it doesn't --- at least not on machines where MAXALIGN is eight
bytes.

I don't think this is worth the trouble...

			regards, tom lane

Fri, 20 Jul 2001 11:29:28 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: OID wraparound (was Re: pg_depend) 