postgresql/contrib/postgres_fdw/Makefile

# contrib/postgres_fdw/Makefile

MODULE_big = postgres_fdw
OBJS = postgres_fdw.o option.o deparse.o connection.o shippable.o $(WIN32RES)
PGFILEDESC = "postgres_fdw - foreign data wrapper for PostgreSQL"

PG_CPPFLAGS = -I$(libpq_srcdir)
SHLIB_LINK = $(libpq)

EXTENSION = postgres_fdw
DATA = postgres_fdw--1.0.sql

REGRESS = postgres_fdw

ifdef USE_PGXS
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
else
SHLIB_PREREQS = submake-libpq
subdir = contrib/postgres_fdw
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
endif
Add postgres_fdw contrib module. There's still a lot of room for improvement, but it basically works, and we need this to be present before we can do anything much with the writable-foreign-tables patch. So let's commit it and get on with testing. Shigeru Hanada, reviewed by KaiGai Kohei and Tom Lane 2013-02-21 18:26:23 +08:00			`# contrib/postgres_fdw/Makefile`

			`MODULE_big = postgres_fdw`
Allow postgres_fdw to ship extension funcs/operators for remote execution. The user can whitelist specified extension(s) in the foreign server's options, whereupon we will treat immutable functions and operators of those extensions as candidates to be sent for remote execution. Whitelisting an extension in this way basically promises that the extension exists on the remote server and behaves compatibly with the local instance. We have no way to prove that formally, so we have to rely on the user to get it right. But this seems like something that people can usually get right in practice. We might in future allow functions and operators to be whitelisted individually, but extension granularity is a very convenient special case, so it got done first. The patch as-committed lacks any regression tests, which is unfortunate, but introducing dependencies on other extensions for testing purposes would break "make installcheck" scenarios, which is worse. I have some ideas about klugy ways around that, but it seems like material for a separate patch. For the moment, leave the problem open. Paul Ramsey, hacked up a bit more by me 2015-11-04 07:42:02 +08:00			`OBJS = postgres_fdw.o option.o deparse.o connection.o shippable.o $(WIN32RES)`
Add file version information to most installed Windows binaries. Prominent binaries already had this metadata. A handful of minor binaries, such as pg_regress.exe, still lack it; efforts to eliminate such exceptions are welcome. Michael Paquier, reviewed by MauMau. 2014-07-15 02:07:52 +08:00			`PGFILEDESC = "postgres_fdw - foreign data wrapper for PostgreSQL"`
Add postgres_fdw contrib module. There's still a lot of room for improvement, but it basically works, and we need this to be present before we can do anything much with the writable-foreign-tables patch. So let's commit it and get on with testing. Shigeru Hanada, reviewed by KaiGai Kohei and Tom Lane 2013-02-21 18:26:23 +08:00
			`PG_CPPFLAGS = -I$(libpq_srcdir)`
			`SHLIB_LINK = $(libpq)`

			`EXTENSION = postgres_fdw`
			`DATA = postgres_fdw--1.0.sql`

			`REGRESS = postgres_fdw`

			`ifdef USE_PGXS`
			`PG_CONFIG = pg_config`
			`PGXS := $(shell $(PG_CONFIG) --pgxs)`
			`include $(PGXS)`
			`else`
Fix SHLIB_PREREQS use in contrib, allowing PGXS builds dblink and postgres_fdw use SHLIB_PREREQS = submake-libpq to build libpq first. This doesn't work in a PGXS build, because there is no libpq to build. So just omit setting SHLIB_PREREQS in this case. Note that PGXS users can still use SHLIB_PREREQS (although it is not documented). The problem here is only that contrib modules can be built in-tree or using PGXS, and the prerequisite is only applicable in the former case. Commit 6697aa2bc25c83b88d6165340348a31328c35de6 previously attempted to address this by creating a somewhat fake submake-libpq target in Makefile.global. That was not the right fix, and it was also done in a nonportable way, so revert that. 2014-12-04 20:58:12 +08:00			`SHLIB_PREREQS = submake-libpq`
Add postgres_fdw contrib module. There's still a lot of room for improvement, but it basically works, and we need this to be present before we can do anything much with the writable-foreign-tables patch. So let's commit it and get on with testing. Shigeru Hanada, reviewed by KaiGai Kohei and Tom Lane 2013-02-21 18:26:23 +08:00			`subdir = contrib/postgres_fdw`
			`top_builddir = ../..`
			`include $(top_builddir)/src/Makefile.global`
			`include $(top_srcdir)/contrib/contrib-global.mk`
			`endif`