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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rationalizing code-sharing among src/bin/ directories
Date: 2016-03-23 19:38:31
Message-ID: 17008.1458761911@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jediný 2016-03-23 19:40:54 Re: BRIN is missing in multicolumn indexes documentation
Previous Message Petr Jelinek 2016-03-23 19:33:38 Re: Relation extension scalability