Re: generic pseudotype IO functions? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: generic pseudotype IO functions?
Date
Msg-id 20140107152104.GE14280@awork2.anarazel.de
Whole thread Raw
In response to Re: generic pseudotype IO functions?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: generic pseudotype IO functions?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-01-07 10:04:33 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > I think we also should auto-assign the oids for pg_proc (and some other
> > tables) rows if we go there.
> 
> -1 ... you've evidently not built any opclasses lately.

True. Not sure if I ever built one, but when playing around.

To the point that I am not seing the problem right now. I am not
proposing to get rid of statically assigned oids in pg_type et al.. The
references to procs mostly seem to be typed 'regproc' so there aren't
many references to function's oids. There's a few procs that are
involved in bootstraping, those likely would need to keep a fixed oid,
but that doesn't sound problematic to me.

> Yeah, we could probably improve the bootstrap infrastructure enough to not
> need literal OIDs in so many places in the initial catalog contents, but
> it'd be lots of trouble.  It definitely is *not* something to buy into at
> the same time as redoing the creation of the .bki file.

Not sure. Any such infrastructure should have support for filling in
defaults for things that don't need to be specified - imo generating an
oid for that sounds like it would fit in there. Doesn't - and possibly
shouldn't - be the same commit though.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: cleanup in code
Next
From: Tom Lane
Date:
Subject: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier