From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: generic pseudotype IO functions? |
Date: | 2014-01-07 15:21:04 |
Message-ID: | 20140107152104.GE14280@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-01-07 10:04:33 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-07 15:27:14 | Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier |
Previous Message | Tom Lane | 2014-01-07 15:20:23 | Re: cleanup in code |