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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rationalizing code-sharing among src/bin/ directories
Date: 2016-03-24 03:54:02
Message-ID: 29702.1458791642@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Having said that, I also notice these dependencies:
> ...
> src/bin/initdb/encnames.c -> ../../../src/backend/utils/mb/encnames.c
> src/interfaces/libpq/encnames.c -> ../../../src/backend/utils/mb/encnames.c
> ...
> which seem like they'd be better handled by moving those files into
> src/common/.

After poking around a bit, it seems like it ought to be a win to move
both encnames.c and wchar.c into src/common/, as both of those modules
are meant to be built for both backend and frontend environments. The
stumbling block is pg_wchar.h, which is a total fail modularity-wise,
as it does not bother to distinguish stuff which should be visible to the
general backend from stuff which should be visible to frontend programs
from stuff which is solely of interest to encoding conversion logic (and
in many cases only to *particular* conversions). I think we should not do
this move without figuring out which parts of that file sanely belong in a
src/include/common/ header file and which don't. That's not something
that I feel like tackling right now, as it's been in that same messy state
for awhile and recent changes haven't made it worse. But it ought to be
revisited at some point.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2016-03-24 04:01:47 Re: Odd system-column handling in postgres_fdw join pushdown patch
Previous Message Peter Geoghegan 2016-03-24 03:28:31 Re: Using quicksort for every external sort run