Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless) - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Date
Msg-id CADkLM=dZQRSqmO1aqDXbFRXp88C1RUsLTKLuEwBZYKpmqY-YLA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Sun, Mar 19, 2017 at 4:23 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Hello Tom,

I'm not entirely convinced that function-per-command is an improvement
though. [...]

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?

My 0.02€:

I've already provided my view...

Personnally I like good functions. Maybe a per-command-family set of functions could improve the code readability, but (1) I'm not sure this is achieved by this patch (eg the if-related state management is now dispatched in 4 functions) and (2) I'm not sure that this approach helps much with respect to trying to factor out backslash-command-related active-or-not argument management.

However I have not looked at the patch in detail. I'm planing to do so later this week.

I offered to split the patch into two steps (1. break each "family" into it's own function and 2. Do what's needed for \if-\endif) but got no response. I can still do that if people think it's worthwhile. 

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)
Next
From: Corey Huinker
Date:
Subject: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)