From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Fabien COELHO <coelho@cri.ensmp.fr>,
        Corey Huinker <corey.huinker@gmail.com>,
        Daniel Verite <daniel@manitou-mail.org>,
        "David G. Johnston" <david.g.johnston@gmail.com>,
        Greg Stark <stark@mit.edu>, Erik Rijkers <er@xs4all.nl>,
        Robert Haas <robertmhaas@gmail.com>,
        Jim Nasby <Jim.Nasby@bluetreble.com>,
        PostgreSQL <pgsql-hackers@postgresql.org>,
        pgsql-hackers-owner@postgresql.org
Subject: Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if,
 \quit_unless)
In-reply-to: <20170319172643.asukyqvva724phnz@alvherre.pgsql>
References: <20170319172643.asukyqvva724phnz@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Sun, 19 Mar 2017 14:26:43 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27328.1489945688.1@sss.pgh.pa.us>
Date: Sun, 19 Mar 2017 13:48:08 -0400
Message-ID: <27329.1489945688@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> The reason this is so large is that there is an entangled refactoring
> patch, splitting the exec_command() function from one giant switch()
> into one routine for each command.  It's up to the committer whether to
> do it all in one patch, or to request this to be split into a
> refactoring patch plus another adding functionality on top.

Assuming we want to do it that way at all, two steps would probably be
easier to review in detail.

I'm not entirely convinced that function-per-command is an improvement
though.  Seems like it would only help to the extent that you could do a
simple "return" to implement early exit, and it looks to me like that
doesn't work in a lot of places because you still have to clean up things
like malloc'd argument strings before you can return.  So the question
we have to answer is whether this way looks cleaner than what we'd get if
we just changed the logic in-place.  For the purpose of answering that
question, looking at the final state is the right thing to do.

I don't have a definite opinion on that core question yet, since I've not
read this version of the patch.  Anybody else want to give an opinion?

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers