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)  (Corey Huinker <corey.huinker@gmail.com>)
Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: [HACKERS] Re: [COMMITTERS] pgsql: Remove all references to "xlog" fromSQL-callable functions in p
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] WIP: About CMake v2