From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Rationalizing code-sharing among src/bin/ directories |
Date: | 2016-03-23 20:00:50 |
Message-ID: | 20160323200050.GA617930@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2016-03-23 20:01:05 | Re: Relation extension scalability |
Previous Message | Robert Haas | 2016-03-23 19:43:12 | Re: Relation extension scalability |