Re: Rationalizing code-sharing among src/bin/ directories - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rationalizing code-sharing among src/bin/ directories
Date
Msg-id 17008.1458761911@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rationalizing code-sharing among src/bin/ directories  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Rationalizing code-sharing among src/bin/ directories
Re: Rationalizing code-sharing among src/bin/ directories
List 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 by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: Relation extension scalability
Next
From: Petr Jediný
Date:
Subject: Re: BRIN is missing in multicolumn indexes documentation