Re: Rationalizing code-sharing among src/bin/ directories

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rationalizing code-sharing among src/bin/ directories
Дата
Msg-id 17008.1458761911@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rationalizing code-sharing among src/bin/ directories  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Rationalizing code-sharing among src/bin/ directories  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Rationalizing code-sharing among src/bin/ directories  (Aleksey Demakov <a.demakov@postgrespro.ru>)
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Note: the reason for a new subdirectory, rather than putting this
>> stuff into src/common/, is that src/common/ is meant for code that's
>> shared between frontend and backend, which this stuff is not.  Also,
>> many of these files depend on libpq which seems like an inappropriate
>> dependency for src/common.

> Actually you could just list them in OBJS_FRONTEND in src/common.  That
> way they're not built for the server at all; no need for a new subdir.

Meh.  I think stuff in OBJS_FRONTEND has to be pretty weird special
cases, such as frontend emulations of server-environment code.  Which
is what fe_memutils is, so that's OK, but I kinda question whether
restricted_token.c belongs in src/common/ at all.

> The libpq dependency argument AFAICS only applies to the ones in
> src/bin/psql.  Perhaps we could have feutils with those only, and move
> the other files to src/common.

On looking closer, the only one that doesn't depend on libpq is
keywords.c, which seems like it belongs in the same place as kwlookup.c.
So yeah, let's move both of those to src/common.

Anybody want to bikeshed the directory name src/feutils?  Maybe fe-utils
would be more readable.  And where to put the corresponding header files?
src/include/fe-utils?
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: Relation extension scalability
Следующее
От: Petr Jediný
Дата:
Сообщение: Re: BRIN is missing in multicolumn indexes documentation