Date: Tue, 5 Aug 2025 21:20:09 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: =?iso-8859-1?Q?=C1lvaro?= Herrera <alvherre@kurilemu.de>,
	pgsql-hackers@postgresql.org
Subject: Re: fix ancient typo in transformRelOptions()
Message-ID: <aJK72dWoPnTZrB63@nathan>
References: <202508052156.d7n5jjro3jne@alvherre.pgsql>
 <1290107.1754431854@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1290107.1754431854@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/aJK72dWoPnTZrB63%40nathan>
Precedence: bulk

On Tue, Aug 05, 2025 at 06:10:54PM -0400, Tom Lane wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
>> On 2025-Aug-05, Nathan Bossart wrote:
>>> I noticed that this function has a "namspace" parameter.  The attached
>>> patch adds the missing 'e'.
> 
>> I have vague recollections of it being this way because of "namespace"
>> being a C++ keyword.  (commit is 3a5b77371522, but I don't have energy
>> to look for the discussion right now.)
> 
> Oh, duh -- if you try cpluspluscheck you'll find it's unhappy.
> I didn't locate the discussion of "namspace" either, but I did
> notice that de160e2c0 used "nameSpace" for the same purpose.
> Maybe we should standardize on that?  It looks less like a typo
> than "namspace", for sure.

That explains it.  I didn't find any past discussions about this particular
name, but commit de160e2 was being developed concurrently.  I'll use
nameSpace instead.

-- 
nathan