From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        Julien Rouhaud <rjuju123@gmail.com>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        Thomas Munro <thomas.munro@gmail.com>,
        Daniel Verite <daniel@manitou-mail.org>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Kevin Grittner <kgrittn@gmail.com>
Subject: Re: Add parallelism and glibc dependent only options to reindexdb
In-reply-to: <20190728072813.GB2029@paquier.xyz>
References: <27884.1563811033@sss.pgh.pa.us>
 <20190722170532.GA26019@alvherre.pgsql> <20190728072813.GB2029@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Sun, 28 Jul 2019 16:28:13 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25196.1564322847.1@sss.pgh.pa.us>
Date: Sun, 28 Jul 2019 10:07:27 -0400
Message-ID: <25197.1564322847@sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> Just wondering something...  List cells include one pointer, one
> signed integer and an OID.  The two last entries are basically 4-byte
> each, hence could we reduce a bit the bloat by unifying both of them?

We couldn't really simplify the API that way; for example,
lfirst_int and lfirst_oid *must* be different because they
must return different types.  I think it'd be a bad idea
to have some parts of the API that distinguish the two types
while others pretend they're the same, so there's not much
room for shortening that.

You could imagine unifying the implementations of many of the
_int and _oid functions, but I can't get excited about that.
It would add confusion for not a lot of code savings.

> I understand that the distinction exists because both may not be of
> the same size..

Well, even more to the point, one's signed and one isn't.

In the long run, might we ever switch to 64-bit OIDs?  I dunno.
Now that we kicked them out of user tables, it might be feasible,
but by the same token there's not much pressure to do it.

			regards, tom lane