From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Thomas Munro <thomas.munro@gmail.com>,
        Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
        Justin Pryzby <pryzby@telsasoft.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg15b1: FailedAssertion("val > base",
 File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)
In-reply-to: 
 <CA+TgmoaWBD32wMe7DvgUqQYUCT0+oOQW8Yh8atKX+1jtZHFs7Q@mail.gmail.com>
References: <20220519193839.GT19626@telsasoft.com>
 <208993.1652994963@sss.pgh.pa.us>
 <20220520.120014.1649415417205853644.horikyota.ntt@gmail.com>
 <CA+Tgmob26sUtT8h2tnqttx1WRfi56FrRELs77ANCXvmVMv3w3g@mail.gmail.com>
 <321315.1654027805@sss.pgh.pa.us>
 <CA+hUKG+zSZ8ZkrS0GRhvaRQBMbfKcBJi_XdtA9nDKt4ODXxR1w@mail.gmail.com>
 <CA+TgmoaWZ-hs1vQ8C88ZE57oXpsWj5oxYZYR9y7c2H+uoikz_A@mail.gmail.com>
 <331489.1654031367@sss.pgh.pa.us>
 <CA+hUKGKWXaUHS7MZxxTYXGZ-04QeftwK+eeaycoQ3q7=+t9PTQ@mail.gmail.com>
 <347628.1654033929@sss.pgh.pa.us>
 <CA+TgmoY7yhdRDibcuuF7Kn2hr7pfS031zuRa1TF8CXvmLq8pdA@mail.gmail.com>
 <351605.1654035253@sss.pgh.pa.us>
 <CA+TgmoaWBD32wMe7DvgUqQYUCT0+oOQW8Yh8atKX+1jtZHFs7Q@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 31 May 2022 18:29:14 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <355849.1654036763.1@sss.pgh.pa.us>
Date: Tue, 31 May 2022 18:39:23 -0400
Message-ID: <355850.1654036763@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/355850.1654036763%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 31, 2022 at 6:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> However, now that I've corrected that mistaken image ... I wonder if
>> it could make sense to redefine relptr as self-relative?  That ought
>> to provide some notational savings since you'd only need to carry
>> around the relptr's own address not that plus a base address.
>> Probably not something to consider for v15 though.

> I think that would be pretty hard to make work, since copying around a
> relative pointer would change its meaning. Code like "relptr_foo x =
> *y" would be broken, for example, but the compiler would not complain.

Sure, but the current definition is far from error-proof as well:
nothing stops you from using the wrong base address with a relptr's
value.  Anyway, it's just idle speculation at this point.

			regards, tom lane