Feedback-ID: i131946ab:Fastmail
Message-ID: <924d08b2-0fb0-a97e-2e2e-7c365ea42f0c@enterprisedb.com>
Date: Mon, 5 Dec 2022 23:40:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.5.1
Subject: Re: initdb: Refactor PG_CMD_PUTS loops
To: Andrew Dunstan <andrew@dunslane.net>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <2c50823b-f453-bb97-e38b-34751c51dcdf@enterprisedb.com>
 <962a4a82-ec18-6a4f-7002-4edb2a47b94c@dunslane.net>
Content-Language: en-US
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <962a4a82-ec18-6a4f-7002-4edb2a47b94c@dunslane.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/924d08b2-0fb0-a97e-2e2e-7c365ea42f0c%40enterprisedb.com>
Precedence: bulk

On 02.12.22 15:07, Andrew Dunstan wrote:
> On 2022-12-01 Th 05:02, Peter Eisentraut wrote:
>> Keeping the SQL commands that initdb runs in string arrays before
>> feeding them to PG_CMD_PUTS() seems unnecessarily verbose and
>> inflexible.  In some cases, the array only has one member.  In other
>> cases, one might want to use PG_CMD_PRINTF() instead, to parametrize a
>> command, but that would require breaking up the loop or using
>> workarounds like replace_token().  This patch unwinds all that; it's
>> much simpler that way.
> 
> Looks reasonable. (Most of this dates back to 2003/2004, the very early
> days of initdb.c.)

committed