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