[Pkg-postgresql-public] pg_bulkload package sponsorship

Alexander acca at cpan.org
Thu May 31 04:04:57 UTC 2012

Many thanks, Christoph,

On Wed, May 30, 2012 at 6:55 PM, Christoph Berg <cb at df7cb.de> wrote:
>> A solution which could work may be to make configure() in pg_buildext
>> to create a copy of $srcdir in $vtarget, but there is also a  package
>> dependency problem.
> Don't do that, that's exactly what VPATH is meant to avoid.
> Having said that, there's plenty of weird make features that are hard
> to get around, we should probably add a mode of operation to
> pg_buildext that does not do out-of-tree builds.

I guess `cp -arl' should be good enough. Out-of-tree build, 0 bytes
space overhead. Having no patch to Makefiles even saves a couple of
kilobytes. If libpq version issue can be resolved.

>> libpq and libpq-dev are packages of a certain version with no version
>> segregation. While I may have postgresql-server-dev-8.4 and
>> postgresql-server-dev-9.1 together, the latter brings libpq-dev (>=
>> 9.1~) with its /usr/include/postgresql/pg_config.h. As a result a
>> version-aware source gets controversial data from pg_config.h and
>> pg_config and finally breaks somewhere.
> I haven't yet seen a package where this is a problem. libpq (and hence
> its include files) should be compatible enough across different server
> version. (If not, that means that file should probably be moved to
> /usr/include/postgresql/*.*/server.)

The problem is not libpq per se, but PG_VERSION_NUM in

pg_bulkload heavily uses it to determine, say, proper arguments for
certain server function calls. Now what pg_buildext suggests is, say,
8.4-server include files. What PG_VERSION_NUM triggers is 9.1-server
function calls.

-DPG_VERSION_NUM gets overriden by
/usr/include/postgresql/pg_config.h. pg_config.h itself is generated
and does not have any conditions. Hacking
/usr/include/postgresql/pg_config.h on the fly seems to be mauvais
ton. The same about carrying possible versions of pg_config.h. Merely
substitution of PG_VERSION_STR is already a dirty hack.

Which implies in-the-tree build in different environment for every
version of PostgreSQL. Long live OpenVZ.

Sincerely yours, Alexander Kuznetsov

More information about the Pkg-postgresql-public mailing list