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=decErx7iFyzxuPMQ5DNd6dearn+VuE1ajWKA_NaaMtug@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
List pgsql-hackers
On Mon, Feb 13, 2017 at 11:26 AM, Corey Huinker <corey.huinker@gmail.com> wrote:
ISTM that it is kind of a regression, because logically this is about the scan state so it should be in the corresponding structure, and having two structures to pass the scan state is not an improvement...

I wasn't too happy with the extra param, either. Having moved the guts to conditional.c, I'm happy with that change and can move the stack head back to scan_state with a clear conscience.

So moving the conditional stack back into PsqlScanState has some side effects: conditional.[ch] have to move to the fe_utils/ dirs, and now pgbench, which does not use conditionals, would have to link to them. Is that a small price to pay for modularity and easier-to-find code? Or should I just tuck it back into psqlscan_int.[ch]?

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: [HACKERS] Re: [COMMITTERS] pgsql: Remove all references to "xlog" fromSQL-callable functions in p
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] WIP: About CMake v2