postgresql/contrib/intagg/Makefile

# contrib/intagg/Makefile

EXTENSION = intagg
DATA = intagg--1.1.sql intagg--1.0--1.1.sql

ifdef USE_PGXS
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
else
subdir = contrib/intagg
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
endif
Remove cvs keywords from all files. 2010-09-20 16:08:53 -04:00			`# contrib/intagg/Makefile`
Add integer aggregator to /contrib. mlw 2002-02-24 22:45:27 -05:00
Rethink naming of contrib/intagg extension. Initially it was called int_aggregate after the old SQL file, but since the documentation just says "intagg" and that's also the directory name, let's conform to that instead. 2011-02-14 20:59:42 -05:00			`EXTENSION = intagg`
Remove support for upgrading extensions from "unpackaged" state. Andres Freund pointed out that allowing non-superusers to run "CREATE EXTENSION ... FROM unpackaged" has security risks, since the unpackaged-to-1.0 scripts don't try to verify that the existing objects they're modifying are what they expect. Just attaching such objects to an extension doesn't seem too dangerous, but some of them do more than that. We could have resolved this, perhaps, by still requiring superuser privilege to use the FROM option. However, it's fair to ask just what we're accomplishing by continuing to lug the unpackaged-to-1.0 scripts forward. None of them have received any real testing since 9.1 days, so they may not even work anymore (even assuming that one could still load the previous "loose" object definitions into a v13 database). And an installation that's trying to go from pre-9.1 to v13 or later in one jump is going to have worse compatibility problems than whether there's a trivial way to convert their contrib modules into extension style. Hence, let's just drop both those scripts and the core-code support for "CREATE EXTENSION ... FROM". Discussion: https://postgr.es/m/20200213233015.r6rnubcvl4egdh5r@alap3.anarazel.de 2020-02-19 16:59:14 -05:00			`DATA = intagg--1.1.sql intagg--1.0--1.1.sql`
Add integer aggregator to /contrib. mlw 2002-02-24 22:45:27 -05:00
> Please find enclose a submission to fix these problems. > > The patch adds missing the "libpgport.a" file to the installation under > "install-all-headers". It is needed by some contribs. I install the > library in "pkglibdir", but I was wondering whether it should be "libdir"? > I was wondering also whether it would make sense to have a "libpgport.so"? > > It fixes various macros which are used by contrib makefiles, especially > libpq_*dir and LDFLAGS when used under PGXS. It seems to me that they are > needed to > > It adds the ability to test and use PGXS with contribs, with "make > USE_PGXS=1". Without the macro, this is exactly as before, there should be > no difference, esp. wrt the vpath feature that seemed broken by previous > submission. So it should not harm anybody, and it is useful at least to me. > > It fixes some inconsistencies in various contrib makefiles > (useless override, ":=" instead of "="). Fabien COELHO 2004-08-20 16:13:10 -04:00			`ifdef USE_PGXS`
Fix PGXS conventions so that extensions can be built against Postgres installations whose pg_config program does not appear first in the PATH. Per gripe from Eddie Stanley and subsequent discussions with Fabien Coelho and others. 2007-06-26 18:05:04 -04:00			`PG_CONFIG = pg_config`
			`PGXS := $(shell $(PG_CONFIG) --pgxs)`
> Please find enclose a submission to fix these problems. > > The patch adds missing the "libpgport.a" file to the installation under > "install-all-headers". It is needed by some contribs. I install the > library in "pkglibdir", but I was wondering whether it should be "libdir"? > I was wondering also whether it would make sense to have a "libpgport.so"? > > It fixes various macros which are used by contrib makefiles, especially > libpq_*dir and LDFLAGS when used under PGXS. It seems to me that they are > needed to > > It adds the ability to test and use PGXS with contribs, with "make > USE_PGXS=1". Without the macro, this is exactly as before, there should be > no difference, esp. wrt the vpath feature that seemed broken by previous > submission. So it should not harm anybody, and it is useful at least to me. > > It fixes some inconsistencies in various contrib makefiles > (useless override, ":=" instead of "="). Fabien COELHO 2004-08-20 16:13:10 -04:00			`include $(PGXS)`
			`else`
			`subdir = contrib/intagg`
			`top_builddir = ../..`
			`include $(top_builddir)/src/Makefile.global`
Add integer aggregator to /contrib. mlw 2002-02-24 22:45:27 -05:00			`include $(top_srcdir)/contrib/contrib-global.mk`
> Please find enclose a submission to fix these problems. > > The patch adds missing the "libpgport.a" file to the installation under > "install-all-headers". It is needed by some contribs. I install the > library in "pkglibdir", but I was wondering whether it should be "libdir"? > I was wondering also whether it would make sense to have a "libpgport.so"? > > It fixes various macros which are used by contrib makefiles, especially > libpq_*dir and LDFLAGS when used under PGXS. It seems to me that they are > needed to > > It adds the ability to test and use PGXS with contribs, with "make > USE_PGXS=1". Without the macro, this is exactly as before, there should be > no difference, esp. wrt the vpath feature that seemed broken by previous > submission. So it should not harm anybody, and it is useful at least to me. > > It fixes some inconsistencies in various contrib makefiles > (useless override, ":=" instead of "="). Fabien COELHO 2004-08-20 16:13:10 -04:00			`endif`