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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Rationalizing code-sharing among src/bin/ directories
Дата
Msg-id 20160323200050.GA617930@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Rationalizing code-sharing among src/bin/ directories  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Rationalizing code-sharing among src/bin/ directories  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Rationalizing code-sharing among src/bin/ directories  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Tom Lane wrote:

> > 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.

OK, that makes sense.  Feel free to move restricted_token.c if you feel
like it.

> > 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.

I guess those dependencies are somewhat hidden.  No objections to that
move.

> Anybody want to bikeshed the directory name src/feutils?  Maybe fe-utils
> would be more readable.

Yes, +1 for either a - or _ in there.

> And where to put the corresponding header files?
> src/include/fe-utils?

Sounds fair but would that be installed in PREFIX/include/server?
That'd be a bit odd, but I'm not -1 on that.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: Relation extension scalability
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: NOT EXIST for PREPARE