Horton

Thread

Commits

  1. initdb: Refactor PG_CMD_PUTS loops

  1. initdb: Refactor PG_CMD_PUTS loops

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-12-01T10:02:33Z

    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.

  2. Re: initdb: Refactor PG_CMD_PUTS loops

    John Naylor <john.naylor@enterprisedb.com> — 2022-12-02T07:03:40Z

    On Thu, Dec 1, 2022 at 5:02 PM Peter Eisentraut <
peter.eisentraut@enterprisedb.com> 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.

+1,  I can't think of a reason to keep the current coding

--
John Naylor
EDB: http://www.enterprisedb.com

  3. Re: initdb: Refactor PG_CMD_PUTS loops

    Andrew Dunstan <andrew@dunslane.net> — 2022-12-02T14:07:54Z

    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.)


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

  4. Re: initdb: Refactor PG_CMD_PUTS loops

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-12-05T22:40:54Z

    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