1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgres/contrib/seg/Makefile

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

46 lines
904 B
Makefile
Raw Normal View History

Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
# contrib/seg/Makefile
Gene Selkov's SEG datatype (GiST example code)
2000-12-11 20:40:33 +00:00
To fix the perpetually broken makefiles in the contrib tree, I have written a generic framework of rules that the contrib makefiles can use instead of writing their own each time. You only need to set a few variables and off you go.
2001-09-06 10:49:30 +00:00
MODULE_big = seg
Split all OBJS style lines in makefiles into one-line-per-entry style. When maintaining or merging patches, one of the most common sources for conflicts are the list of objects in makefiles. Especially when the split across lines has been changed on both sides, which is somewhat common due to attempting to stay below 80 columns, those conflicts are unnecessarily laborious to resolve. By splitting, and alphabetically sorting, OBJS style lines into one object per line, conflicts should be less frequent, and easier to resolve when they still occur. Author: Andres Freund Discussion: https://postgr.es/m/20191029200901.vww4idgcxv74cwes@alap3.anarazel.de
2019-11-05 14:41:07 -08:00
OBJS = \
$(WIN32RES) \
seg.o \
Build all Flex files standalone The proposed Meson build system will need a way to ignore certain generated files in order to coexist with the autoconf build system, and C files generated by Flex which are #include'd into .y files make this more difficult. In similar vein to 72b1e3a21, arrange for all Flex C files to compile to their own .o targets. Reviewed by Andres Freund Discussion: https://www.postgresql.org/message-id/20220810171935.7k5zgnjwqzalzmtm%40awork3.anarazel.de Discussion: https://www.postgresql.org/message-id/CAFBsxsF8Gc2StS3haXofshHCzqNMRXiSxvQEYGwnFsTmsdwNeg@mail.gmail.com
2022-09-04 11:33:31 +07:00
segparse.o \
segscan.o
Convert contrib modules to use the extension facility. This isn't fully tested as yet, in particular I'm not sure that the "foo--unpackaged--1.0.sql" scripts are OK. But it's time to get some buildfarm cycles on it. sepgsql is not converted to an extension, mainly because it seems to require a very nonstandard installation process. Dimitri Fontaine and Tom Lane
2011-02-13 20:06:41 -05:00
EXTENSION = seg
Remove deprecated containment operators for contrib types. Since PG 8.2, @ and ~ have been deprecated aliases for the containment operators @> and <@. It seems like enough time has passed to actually remove them, so do so. This completes the project begun in commit 2f70fdb06. Note that in the core types, the relation to the preferred operator names was reversed from what it is in these contrib modules. The confusion that induced was a large part of the reason for deprecation. Justin Pryzby Discussion: https://postgr.es/m/20201027032511.GF9241@telsasoft.com
2021-03-05 10:45:41 -05:00
DATA = seg--1.1.sql seg--1.1--1.2.sql seg--1.2--1.3.sql seg--1.3--1.4.sql \
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
seg--1.0--1.1.sql
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-14 14:07:52 -04:00
PGFILEDESC = "seg - line segment data type"
Convert contrib modules to use the extension facility. This isn't fully tested as yet, in particular I'm not sure that the "foo--unpackaged--1.0.sql" scripts are OK. But it's time to get some buildfarm cycles on it. sepgsql is not converted to an extension, mainly because it seems to require a very nonstandard installation process. Dimitri Fontaine and Tom Lane
2011-02-13 20:06:41 -05:00
Provide for contrib and pgxs modules to install include files. This allows out-of-tree PLs and similar code to get access to definitions needed to work with extension data types. The following existing modules now install headers: contrib/cube, contrib/hstore, contrib/isn, contrib/ltree, contrib/seg. Discussion: https://postgr.es/m/87y3euomjh.fsf%40news-spur.riddles.org.uk
2018-07-31 19:58:39 +01:00
HEADERS = segdata.h
Replace last PushOverrideSearchPath() call with set_config_option(). The two methods don't cooperate, so set_config_option("search_path", ...) has been ineffective under non-empty overrideStack. This defect enabled an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. While that particular attack requires v13+ for the trusted extension attribute, other attacks are feasible in all supported versions. Standardize on the combination of NewGUCNestLevel() and set_config_option("search_path", ...). It is newer than PushOverrideSearchPath(), more-prevalent, and has no known disadvantages. The "override" mechanism remains for now, for compatibility with out-of-tree code. Users should update such code, which likely suffers from the same sort of vulnerability closed here. Back-patch to v11 (all supported versions). Alexander Lakhin. Reported by Alexander Lakhin. Security: CVE-2023-2454
2023-05-08 06:14:07 -07:00
REGRESS = security seg
Gene Selkov's SEG datatype (GiST example code)
2000-12-11 20:40:33 +00:00
Put flex'ed and bison'ed files in contrib in the distribution tarball, as is done for the analogous files in the main distribution.
2006-04-03 18:47:41 +00:00
EXTRA_CLEAN = y.tab.c y.tab.h
> 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 20:13:10 +00: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 22:05:04 +00: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 20:13:10 +00:00
include $(PGXS)
else
subdir = contrib/seg
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
endif
Gene Selkov's SEG datatype (GiST example code)
2000-12-11 20:40:33 +00:00
Make all our flex and bison files use %option prefix or %name-prefix (respectively) to rename yylex and related symbols. Some were doing it this way already, while others used not-too-reliable sed hacks in the Makefiles. It's all nice and consistent now.
2006-03-07 01:03:12 +00:00
Build all Flex files standalone The proposed Meson build system will need a way to ignore certain generated files in order to coexist with the autoconf build system, and C files generated by Flex which are #include'd into .y files make this more difficult. In similar vein to 72b1e3a21, arrange for all Flex C files to compile to their own .o targets. Reviewed by Andres Freund Discussion: https://www.postgresql.org/message-id/20220810171935.7k5zgnjwqzalzmtm%40awork3.anarazel.de Discussion: https://www.postgresql.org/message-id/CAFBsxsF8Gc2StS3haXofshHCzqNMRXiSxvQEYGwnFsTmsdwNeg@mail.gmail.com
2022-09-04 11:33:31 +07:00
# See notes in src/backend/parser/Makefile about the following two rules
segparse.h: segparse.c
touch $@
segparse.c: BISONFLAGS += -d
# Force these dependencies to be known even without dependency info built:
segparse.o segscan.o: segparse.h
Arrange to compile flex output files as inclusions into other files (usually bison output files), not as standalone files. This hack works around flex's insistence on including <stdio.h> before we are able to include postgres.h; postgres.h will already be read before the compiler starts to read the flex output file. Needed for largefile support on some platforms.
2002-11-01 22:52:34 +00:00
Derived files that are shipped in the distribution used to be built in the source directory even for out-of-tree builds. They are now alsl built in the build tree. This should be more convenient for certain developers' workflows, and shouldn't really break anything else.
2009-08-28 20:26:19 +00:00
distprep: segparse.c segscan.c
Put flex'ed and bison'ed files in contrib in the distribution tarball, as is done for the analogous files in the main distribution.
2006-04-03 18:47:41 +00:00
maintainer-clean:
Build all Flex files standalone The proposed Meson build system will need a way to ignore certain generated files in order to coexist with the autoconf build system, and C files generated by Flex which are #include'd into .y files make this more difficult. In similar vein to 72b1e3a21, arrange for all Flex C files to compile to their own .o targets. Reviewed by Andres Freund Discussion: https://www.postgresql.org/message-id/20220810171935.7k5zgnjwqzalzmtm%40awork3.anarazel.de Discussion: https://www.postgresql.org/message-id/CAFBsxsF8Gc2StS3haXofshHCzqNMRXiSxvQEYGwnFsTmsdwNeg@mail.gmail.com
2022-09-04 11:33:31 +07:00
rm -f segparse.h segparse.c segscan.c
Reference in New Issue Copy Permalink