Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
| От | Corey Huinker |
|---|---|
| Тема | Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless) |
| Дата | |
| Msg-id | CADkLM=decErx7iFyzxuPMQ5DNd6dearn+VuE1ajWKA_NaaMtug@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless) (Corey Huinker <corey.huinker@gmail.com>) |
| Ответы |
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) |
| Список | 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 по дате отправления: