Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Fri, Mar 25, 2016 at 12:55 PM, Tom Lane wrote: > Michael Paquier writes: >> Not sure if Andres is working on that for now or not, the main >> discussion that I am foreseeing here is how we are going to map elevel >> for the frontend (should

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Michael Paquier writes: > Not sure if Andres is working on that for now or not, the main > discussion that I am foreseeing here is how we are going to map elevel > for the frontend (should FATAL, PANIC exit immediately, etc). Doesn't seem that complicated to me: elevel

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Fri, Mar 25, 2016 at 9:52 AM, Tom Lane wrote: > Michael Paquier writes: >> Preventing the use of elog in the frontend is something that has been >> addressed multiple times with FRONTEND, so that's not likely going to >> be an issue I think.

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Michael Paquier writes: > On Fri, Mar 25, 2016 at 1:11 AM, Alvaro Herrera > wrote: >> I wondered about the list stuff while messing about in pg_dump awhile >> ago. It seems moderately okay, but not terribly generic; maybe we >> should get rid

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Fri, Mar 25, 2016 at 1:11 AM, Alvaro Herrera wrote: > Tom Lane wrote: > >> What I propose doing is leaving the above-listed items in >> pg_dump/dumputils.h/.c, and moving the rest of what's in those files >> to new files src/include/fe_utils/string_utils.h and >>

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Aleksey Demakov writes: > Hi there, >> On 23 Mar 2016, at 22:38, Tom Lane wrote: >> Anybody want to bikeshed the directory name src/feutils? Maybe fe-utils >> would be more readable. And where to put the corresponding header files? >>

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Hi there, > On 23 Mar 2016, at 22:38, Tom Lane wrote: > 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? For me “utils" sounds like something of

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Alvaro Herrera writes: > Tom Lane wrote: >> This name is a bit arbitrary, but most of what's there is string >> processing of some flavor or other, with some list processing thrown >> in for good measure. If anyone's got a different color to paint this >> bikeshed,

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > What I propose doing is leaving the above-listed items in > pg_dump/dumputils.h/.c, and moving the rest of what's in those files > to new files src/include/fe_utils/string_utils.h and > src/fe_utils/string_utils.c. Seems reasonable. > This name is a bit arbitrary, but most of

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Wed, Mar 23, 2016 at 4:00 PM, Alvaro Herrera wrote: >> Anybody want to bikeshed the directory name src/feutils? Maybe fe-utils >> would be more readable. > > Yes, +1 for either a - or _ in there. I vote for an underscore, since that's what we mostly do. [rhaas

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

I wrote: > I have a modest proposal for improving this: let's move all the code > that's currently shared by two or more src/bin/ subdirectories into a > new directory, say src/feutils, and build it into a ".a" library in > the same way that src/common/ is handled. Moving along on this project:

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Robert Haas writes: > On Wed, Mar 23, 2016 at 4:00 PM, Alvaro Herrera > wrote: >> Yes, +1 for either a - or _ in there. > I vote for an underscore, since that's what we mostly do. Yup, I had just counted and come to the same conclusion.

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

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 >

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> 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. > >

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Alvaro Herrera writes: > Tom Lane wrote: >> 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. The only other plan I can think of

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > Alvaro Herrera 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

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

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

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

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

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Wed, Mar 23, 2016 at 5:55 PM, Tom Lane wrote: > I'm not terribly happy with the hack I used to get pgbench to be able > to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build > scripts, and I have seen it causing two concurrent builds of psqlscan.o > in

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On 23/03/16 17:55, Tom Lane wrote: I'm not terribly happy with the hack I used to get pgbench to be able to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build scripts, and I have seen it causing two concurrent builds of psqlscan.o in parallel builds, which is likely to cause a build

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Wed, Mar 23, 2016 at 12:55 PM, Tom Lane wrote: > I'm not terribly happy with the hack I used to get pgbench to be able > to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build > scripts, and I have seen it causing two concurrent builds of psqlscan.o > in

[HACKERS] Rationalizing code-sharing among src/bin/ directories

I'm not terribly happy with the hack I used to get pgbench to be able to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build scripts, and I have seen it causing two concurrent builds of psqlscan.o in parallel builds, which is likely to cause a build failure some of the time. Another