Re: Patch: initdb: "'" for QUOTE_PATH (non-windows)

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> Regarding your patch, with a bit of clean up it gives the attached.

This fails to build for me, with

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -O1 initdb.o findtimezone.o localtime.o encnames.o -L../../../src/port -L../../../src/common -Wl,--as-needed -Wl,-rpath,'/home/postgres/testversion/lib',--enable-new-dtags -L../../../src/fe_utils -lpgfeutils -lpq -lpgcommon -lpgport -lz -lreadline -lrt -lcrypt -ldl -lm -o initdb
/usr/bin/ld: cannot find -lpq
collect2: ld returned 1 exit status
make: *** [initdb] Error 1

evidently because the link command omits the necessary -L switch, because
you didn't use the approved macro for linking in libpq. It should be
$(libpq_pgport) instead, I believe. (Probably the reason it seems to work
for you is you have a version of libpq.so in /usr/lib; but then you are
really doing the link against the wrong version of libpq.)

A bigger issue here is that it seems fundamentally wrong for initdb to be
including libpq, because it surely is never meant to be communicating
with a running postmaster. Not sure what to do about that. We could
consider moving pqexpbuffer out of libpq into fe_utils, but I wonder
whether that would break any third-party code. We've never advertised
pqexpbuffer.h as a supported API of libpq, but it's probably handy enough
that people use it anyway. I suppose we could duplicate it in fe_utils
and libpq, though that's a tad ugly. Thoughts?

Another perhaps-only-cosmetic issue is that now initdb prints quotes
whether they are needed or not. I find this output pretty ugly:

Success. You can now start the database server using:

'pg_ctl' -D '/home/postgres/testversion/data' -l logfile start

That's not really the fault of this patch perhaps. Maybe we could adjust
appendShellString so it doesn't add quotes if they are clearly
unnecessary.

regards, tom lane