rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/pl/plpython/Makefile

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

153 lines
3.6 KiB
Makefile
Raw Normal View History

Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
# src/pl/plpython/Makefile
Add plpython code.
2001-05-09 21:54:38 +02:00
PL/Python integration: support in create/droplang, add CVS keywords, remove useless files, beat some sense into Makefile. For me it builds and sort of runs, so it's a start.
2001-05-12 03:30:30 +02:00
subdir = src/pl/plpython
top_builddir = ../../..
include $(top_builddir)/src/Makefile.global
Add plpython code.
2001-05-09 21:54:38 +02:00
Fix python_includespec on Windows at configure time By converting to using forward slashes at configure time we avoid having to repeat the logic anywhere that this is needed, such as in transforms modules for plpython.
2015-05-03 14:17:04 +02:00
# On Windows we have to remove -lpython from the link since we are
# building our own
Allow plpython to build on Win32. Magnus Hagander
2004-10-06 11:20:41 +02:00
ifeq ($(PORTNAME), win32)
Replace useless uses of := by = in makefiles.
2007-02-09 16:56:00 +01:00
override python_libspec =
Allow plpython to build on Win32. Magnus Hagander
2004-10-06 11:20:41 +02:00
endif
Unbreak vpath builds broken by commit 474a42473adf9b18417242f1fc0691a857ec578b.
2011-03-01 03:31:39 +01:00
override CPPFLAGS := -I. -I$(srcdir) $(python_includespec) $(CPPFLAGS)
Set rpath for plperl and plpython to ensure we can find the .so files for the languages even when not installed in a standard directory. pltcl may need this treatment as well, but we don't have the right path conveniently available, so I'll leave it alone as long as there aren't actual reports of trouble.
2004-11-19 20:23:01 +01:00
rpathdir = $(python_libdir)
See attached for a small patch that enables plpython to build cleanly under Cygwin. This patch together with my previous Python patch: http://postgresql.readysetnet.com/mhonarc/pgsql-patches/2001-05/msg00075.htm l enables full Python support (i.e., configure --with-python) for Cygwin PostgreSQL. Jason Tishler
2001-05-25 17:48:33 +02:00
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 20:07:52 +02:00
PGFILEDESC = "PL/Python - procedural language"
Python 3 support in PL/Python Behaves more or less unchanged compared to Python 2, but the new language variant is called plpython3u. Documentation describing the naming scheme is included.
2009-12-15 23:59:55 +01:00
NAME = plpython$(python_majorversion)
Create extension infrastructure for the core procedural languages. This mostly just involves creating control, install, and update-from-unpackaged scripts for them. However, I had to adjust plperl and plpython to not share the same support functions between variants, because we can't put the same function into multiple extensions. catversion bump forced due to new contents of pg_pltemplate, and because initdb now installs plpgsql as an extension not a bare language. Add support for regression testing these as extensions not bare languages. Fix a couple of other issues that popped up while testing this: my initial hack at pg_dump binary-upgrade support didn't work right, and we don't want an extra schema permissions test after all. Documentation changes still to come, but I'm committing now to see whether the MSVC build scripts need work (likely they do).
2011-03-05 03:51:14 +01:00
Split plpython.c into smaller pieces This moves the code around from one huge file into hopefully logical and more manageable modules. For the most part, the code itself was not touched, except: PLy_function_handler and PLy_trigger_handler were renamed to PLy_exec_function and PLy_exec_trigger, because they were not actually handlers in the PL handler sense, and it makes the naming more similar to the way PL/pgSQL is organized. The initialization of the procedure caches was separated into a new function init_procedure_caches to keep the hash tables private to plpy_procedures.c. Jan Urbański and Peter Eisentraut
2011-12-18 20:14:16 +01:00
OBJS = \
Fix some OBJS lists in two Makefiles to be ordered alphabetically These have been missed in 01368e5, and count for plpython and the backend's tsearch code. Author: Mahendra Singh Discussion: https://postgr.es/m/CAKYtNAo4mxRRyDB0YqE6QLh17XD7pPQotpGm3GnHS+gQKz4zQQ@mail.gmail.com
2019-12-18 02:42:40 +01:00
$(WIN32RES) \
Split plpython.c into smaller pieces This moves the code around from one huge file into hopefully logical and more manageable modules. For the most part, the code itself was not touched, except: PLy_function_handler and PLy_trigger_handler were renamed to PLy_exec_function and PLy_exec_trigger, because they were not actually handlers in the PL handler sense, and it makes the naming more similar to the way PL/pgSQL is organized. The initialization of the procedure caches was separated into a new function init_procedure_caches to keep the hash tables private to plpy_procedures.c. Jan Urbański and Peter Eisentraut
2011-12-18 20:14:16 +01:00
plpy_cursorobject.o \
plpy_elog.o \
plpy_exec.o \
plpy_main.o \
plpy_planobject.o \
plpy_plpymodule.o \
plpy_procedure.o \
plpy_resultobject.o \
plpy_spi.o \
plpy_subxactobject.o \
plpy_typeio.o \
Fix some OBJS lists in two Makefiles to be ordered alphabetically These have been missed in 01368e5, and count for plpython and the backend's tsearch code. Author: Mahendra Singh Discussion: https://postgr.es/m/CAKYtNAo4mxRRyDB0YqE6QLh17XD7pPQotpGm3GnHS+gQKz4zQQ@mail.gmail.com
2019-12-18 02:42:40 +01:00
plpy_util.o
Add plpython code.
2001-05-09 21:54:38 +02:00
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 22:59:14 +01:00
DATA = $(NAME)u.control $(NAME)u--1.0.sql
Create extension infrastructure for the core procedural languages. This mostly just involves creating control, install, and update-from-unpackaged scripts for them. However, I had to adjust plperl and plpython to not share the same support functions between variants, because we can't put the same function into multiple extensions. catversion bump forced due to new contents of pg_pltemplate, and because initdb now installs plpgsql as an extension not a bare language. Add support for regression testing these as extensions not bare languages. Fix a couple of other issues that popped up while testing this: my initial hack at pg_dump binary-upgrade support didn't work right, and we don't want an extra schema permissions test after all. Documentation changes still to come, but I'm committing now to see whether the MSVC build scripts need work (likely they do).
2011-03-05 03:51:14 +01:00
Fix out-of-tree build for transform modules. Neither plperl nor plpython installed sufficient header files to permit transform modules to be built out-of-tree using PGXS. Fix that by installing all plperl and plpython header files (other than those with special purposes such as generated data tables), and also install plpython's special .mk file for mangling regression tests. (This commit does not fix the windows install, which does not currently install _any_ plperl or plpython headers.) Also fix the existing transform modules for hstore and ltree so that their cross-module #include directives work as anticipated by commit df163230b9 et seq. This allows them to serve as working examples of how to reference other modules when doing separate out-of-tree builds. Discussion: https://postgr.es/m/87o9ej8bgl.fsf%40news-spur.riddles.org.uk
2018-09-16 19:46:45 +02:00
# header files to install - it's not clear which of these might be needed
# so install them all.
INCS = plpython.h \
plpy_cursorobject.h \
plpy_elog.h \
plpy_exec.h \
plpy_main.h \
plpy_planobject.h \
plpy_plpymodule.h \
plpy_procedure.h \
plpy_resultobject.h \
plpy_spi.h \
plpy_subxactobject.h \
plpy_typeio.h \
plpy_util.h
Allow plpython to build on Win32. Magnus Hagander
2004-10-06 11:20:41 +02:00
# Python on win32 ships with import libraries only for Microsoft Visual C++,
# which are not compatible with mingw gcc. Therefore we need to build a
# new import library to link with.
ifeq ($(PORTNAME), win32)
Cosmetic improvements in plpython's make rule for libpython import library. This build technique is remarkably ugly, but that doesn't mean it has to be unreadable too. Be a bit more liberal with the vertical whitespace, and give the .def file a proper dependency, just in case.
2014-02-14 17:31:35 +01:00
Allow plpython to build on Win32. Magnus Hagander
2004-10-06 11:20:41 +02:00
pytverstr=$(subst .,,${python_version})
Cosmetic improvements in plpython's make rule for libpython import library. This build technique is remarkably ugly, but that doesn't mean it has to be unreadable too. Be a bit more liberal with the vertical whitespace, and give the .def file a proper dependency, just in case.
2014-02-14 17:31:35 +01:00
PYTHONDLL=$(subst \,/,$(WINDIR))/system32/python${pytverstr}.dll
Allow plpython to build on Win32. Magnus Hagander
2004-10-06 11:20:41 +02:00
OBJS += libpython${pytverstr}.a
Cosmetic improvements in plpython's make rule for libpython import library. This build technique is remarkably ugly, but that doesn't mean it has to be unreadable too. Be a bit more liberal with the vertical whitespace, and give the .def file a proper dependency, just in case.
2014-02-14 17:31:35 +01:00
Allow plpython to build on Win32. Magnus Hagander
2004-10-06 11:20:41 +02:00
libpython${pytverstr}.a: python${pytverstr}.def
Cosmetic improvements in plpython's make rule for libpython import library. This build technique is remarkably ugly, but that doesn't mean it has to be unreadable too. Be a bit more liberal with the vertical whitespace, and give the .def file a proper dependency, just in case.
2014-02-14 17:31:35 +01:00
dlltool --dllname python${pytverstr}.dll --def python${pytverstr}.def --output-lib libpython${pytverstr}.a
Re-remove dependency on the DLL of pythonxx.def file. The reasons behind commit 0d147e43adcf5d2bff9caa073608f381a27439bf still stand, so this reverts the non-cosmetic portion of commit a7983e989d9cafc9cef49becfee054e34b1ed9b4. Back-patch to 9.4, where the latter commit first appeared.
2014-11-03 03:43:30 +01:00
python${pytverstr}.def:
Use gendef instead of pexports for building windows .def files Modern msys systems lack pexports but have gendef instead, so use that. Discussion: https://postgr.es/m/3ccde7a9-e4f9-e194-30e0-0936e6ad68ba@dunslane.net Backpatch to release 9.4 to enable building with perl on older branches. Before that pexports is not used for plperl.
2022-02-10 19:44:05 +01:00
gendef - $(PYTHONDLL) > $@
Cosmetic improvements in plpython's make rule for libpython import library. This build technique is remarkably ugly, but that doesn't mean it has to be unreadable too. Be a bit more liberal with the vertical whitespace, and give the .def file a proper dependency, just in case.
2014-02-14 17:31:35 +01:00
endif # win32
Allow plpython to build on Win32. Magnus Hagander
2004-10-06 11:20:41 +02:00
Cleanup pass over PL/Python NLS. Add translation support to PLy_elog and PLy_exception_set, and clarify some error messages.
2009-01-15 14:49:57 +01:00
SHLIB_LINK = $(python_libspec) $(python_additional_libs) $(filter -lintl,$(LIBS))
PL/Python should build portably now, if you can get over the fact that there's no shared libpython. Test suite works as well. Also, add some documentation.
2001-05-12 19:49:32 +02:00
Python 3 support in PL/Python Behaves more or less unchanged compared to Python 2, but the new language variant is called plpython3u. Documentation describing the naming scheme is included.
2009-12-15 23:59:55 +01:00
REGRESS_OPTS = --dbname=$(PL_TESTDB)
Make plpythonu language use plpython2 shared library directly. The original scheme for this was to symlink plpython.$DLSUFFIX to plpython2.$DLSUFFIX, but that doesn't work on Windows, and only accidentally failed to fail because of the way that CREATE LANGUAGE created or didn't create new C functions. My changes of yesterday exposed the weakness of that approach. To fix, get rid of the symlink and make pg_pltemplate show what's really going on.
2011-03-05 21:13:15 +01:00
Split the plpython regression test into test cases arranged by topic, instead of the previous monolithic setup-create-run sequence, that was apparently inherited from a previous test infrastructure, but makes working with the tests and adding new ones weird.
2009-08-12 18:37:26 +02:00
REGRESS = \
plpython_schema \
plpython_populate \
plpython_test \
PL/Python DO handler Also cleaned up some redundancies between the primary error messages and the error context in PL/Python. Hannu Valtonen
2010-01-22 16:45:15 +01:00
plpython_do \
Split the plpython regression test into test cases arranged by topic, instead of the previous monolithic setup-create-run sequence, that was apparently inherited from a previous test infrastructure, but makes working with the tests and adding new ones weird.
2009-08-12 18:37:26 +02:00
plpython_global \
plpython_import \
plpython_spi \
plpython_newline \
plpython_void \
SQL procedures This adds a new object type "procedure" that is similar to a function but does not have a return type and is invoked by the new CALL statement instead of SELECT or similar. This implementation is aligned with the SQL standard and compatible with or similar to other SQL implementations. This commit adds new commands CALL, CREATE/ALTER/DROP PROCEDURE, as well as ALTER/DROP ROUTINE that can refer to either a function or a procedure (or an aggregate function, as an extension to SQL). There is also support for procedures in various utility commands such as COMMENT and GRANT, as well as support in pg_dump and psql. Support for defining procedures is available in all the languages supplied by the core distribution. While this commit is mainly syntax sugar around existing functionality, future features will rely on having procedures as a separate object type. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-11-30 14:46:13 +01:00
plpython_call \
Split the plpython regression test into test cases arranged by topic, instead of the previous monolithic setup-create-run sequence, that was apparently inherited from a previous test infrastructure, but makes working with the tests and adding new ones weird.
2009-08-12 18:37:26 +02:00
plpython_params \
plpython_setof \
plpython_record \
plpython_trigger \
PL/Python regression tests for data type handling Add some checks on various data types are converted into and out of Python. This is extracted from Caleb Welton's patch for improved bytea support, but much expanded.
2009-08-14 15:42:16 +02:00
plpython_types \
Split the plpython regression test into test cases arranged by topic, instead of the previous monolithic setup-create-run sequence, that was apparently inherited from a previous test infrastructure, but makes working with the tests and adding new ones weird.
2009-08-12 18:37:26 +02:00
plpython_error \
PL/Python: Move ereport wrapper test cases to separate file In commit 5c3c3cd0a3046339597a03bc708cb5530dc07059, the new tests were apparently just dumped into the first convenient file. Move them to a separate file dedicated to testing that functionality and leave the plpython_test test to test basic functionality, as it did before.
2016-06-07 15:33:41 +02:00
plpython_ereport \
Split the plpython regression test into test cases arranged by topic, instead of the previous monolithic setup-create-run sequence, that was apparently inherited from a previous test infrastructure, but makes working with the tests and adding new ones weird.
2009-08-12 18:37:26 +02:00
plpython_unicode \
Add PL/Python functions for quoting strings Add functions plpy.quote_ident, plpy.quote_literal, plpy.quote_nullable, which wrap the equivalent SQL functions. To be able to propagate char * constness properly, make the argument of quote_literal_cstr() const char *. This also makes it more consistent with quote_identifier(). Jan Urbański, reviewed by Hitoshi Harada, some refinements by Peter Eisentraut
2011-02-22 22:33:44 +01:00
plpython_quote \
Table function support for PL/Python This allows functions with multiple OUT parameters returning both one or multiple records (RECORD or SETOF RECORD). Jan Urbański, reviewed by Hitoshi Harada
2011-02-26 15:53:11 +01:00
plpython_composite \
PL/Python explicit subtransactions Adds a context manager, obtainable by plpy.subtransaction(), to run a group of statements in a subtransaction. Jan Urbański, reviewed by Steve Singer, additional scribbling by me
2011-02-27 16:09:56 +01:00
plpython_subtransaction \
Transaction control in PL procedures In each of the supplied procedural languages (PL/pgSQL, PL/Perl, PL/Python, PL/Tcl), add language-specific commit and rollback functions/commands to control transactions in procedures in that language. Add similar underlying functions to SPI. Some additional cleanup so that transaction commit or abort doesn't blow away data structures still used by the procedure call. Add execution context tracking to CALL and DO statements so that transaction control commands can only be issued in top-level procedure and block calls, not function calls or other procedure or block calls. - SPI Add a new function SPI_connect_ext() that is like SPI_connect() but allows passing option flags. The only option flag right now is SPI_OPT_NONATOMIC. A nonatomic SPI connection can execute transaction control commands, otherwise it's not allowed. This is meant to be passed down from CALL and DO statements which themselves know in which context they are called. A nonatomic SPI connection uses different memory management. A normal SPI connection allocates its memory in TopTransactionContext. For nonatomic connections we use PortalContext instead. As the comment in SPI_connect_ext() (previously SPI_connect()) indicates, one could potentially use PortalContext in all cases, but it seems safest to leave the existing uses alone, because this stuff is complicated enough already. SPI also gets new functions SPI_start_transaction(), SPI_commit(), and SPI_rollback(), which can be used by PLs to implement their transaction control logic. - portalmem.c Some adjustments were made in the code that cleans up portals at transaction abort. The portal code could already handle a command *committing* a transaction and continuing (e.g., VACUUM), but it was not quite prepared for a command *aborting* a transaction and continuing. In AtAbort_Portals(), remove the code that marks an active portal as failed. As the comment there already predicted, this doesn't work if the running command wants to keep running after transaction abort. And it's actually not necessary, because pquery.c is careful to run all portal code in a PG_TRY block and explicitly runs MarkPortalFailed() if there is an exception. So the code in AtAbort_Portals() is never used anyway. In AtAbort_Portals() and AtCleanup_Portals(), we need to be careful not to clean up active portals too much. This mirrors similar code in PreCommit_Portals(). - PL/Perl Gets new functions spi_commit() and spi_rollback() - PL/pgSQL Gets new commands COMMIT and ROLLBACK. Update the PL/SQL porting example in the documentation to reflect that transactions are now possible in procedures. - PL/Python Gets new functions plpy.commit and plpy.rollback. - PL/Tcl Gets new commands commit and rollback. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-01-22 14:30:16 +01:00
plpython_transaction \
Split the plpython regression test into test cases arranged by topic, instead of the previous monolithic setup-create-run sequence, that was apparently inherited from a previous test infrastructure, but makes working with the tests and adding new ones weird.
2009-08-12 18:37:26 +02:00
plpython_drop
Make plpythonu language use plpython2 shared library directly. The original scheme for this was to symlink plpython.$DLSUFFIX to plpython2.$DLSUFFIX, but that doesn't work on Windows, and only accidentally failed to fail because of the way that CREATE LANGUAGE created or didn't create new C functions. My changes of yesterday exposed the weakness of that approach. To fix, get rid of the symlink and make pg_pltemplate show what's really going on.
2011-03-05 21:13:15 +01:00
PL/Python integration: support in create/droplang, add CVS keywords, remove useless files, beat some sense into Makefile. For me it builds and sort of runs, so it's a start.
2001-05-12 03:30:30 +02:00
include $(top_srcdir)/src/Makefile.shlib
Add plpython code.
2001-05-09 21:54:38 +02:00
Fix misplacement of submake-generated-headers prerequisites. The sequence "configure; cd src/pl/plpython; make -j" failed due to trying to compile plpython's .o files before the generated headers finished building. (This is an important real-world case, since it's the typical second step when building both plpython2 and plpython3.) This happens because the submake-generated-headers target is not placed in a way to make it a prerequisite to compiling the .o files. Fix that. Checking other uses of submake-generated-headers, I noted that the one attached to pg_regress was similarly misplaced; but it's actually not needed at all for pg_regress.o, rather regress.o, so move it to be a prerequisite of that. Back-patch to 9.6 where submake-generated-headers was introduced (by commit 548af97fc). It's not immediately clear to me why the previous coding didn't have the same issue; but since we've not had field reports of plpython make failing, leave it alone in the older branches. Pavel Raiskup and Tom Lane Discussion: <1925924.izSMJEZO3x@unused-4-107.brq.redhat.com>
2016-10-01 19:35:13 +02:00
all: all-lib
Put back parallel-safety guards in plpython and src/test/regress/. I'd hoped that commit 3b8f6e75f was sufficient to ensure parallel safety even when a build started in a subdirectory requires rebuilding of generated headers. This isn't so, because making submake-generated-headers a prerequisite of "all" isn't enough to ensure it's completed before starting on "all"'s other prerequisites. The explicit dependencies we put on the recursive make targets ensure safe ordering before we recurse into child directories, but they don't protect targets to be made in the current directory. Hence, put back some ordering dependencies in directories that we've traditionally expected to be starting points for "standalone" builds, to wit src/pl/plpython and src/test/regress. (The former needs this in order to minimize the work involved in building for both python 2 and python 3; the latter to support packagings that make the regression tests available for out-of-build-tree execution.) Adjust some other dependencies so that these two cases work correctly even at high -j settings. I'm not terribly happy with this partial solution, but I don't see a way to do better without massive makefile restructuring, which we surely aren't doing at this point in the development cycle. In any case, it's little if any worse than what we had in prior releases. Discussion: https://postgr.es/m/1523353963.8169.26.camel@gunduz.org
2018-04-10 22:14:55 +02:00
# Ensure parallel safety if a build is started in this directory
$(OBJS): | submake-generated-headers
Fix parallel gmake for extension directory addition in PL languages.
2011-03-06 00:32:06 +01:00
install: all install-lib install-data
Add plpython code.
2001-05-09 21:54:38 +02:00
Implement a few changes to how shared libraries and dynamically loadable modules are built. Foremost, it creates a solid distinction between these two types of targets based on what had already been implemented and duplicated in ad hoc ways before. Specifically, - Dynamically loadable modules no longer get a soname. The numbers previously set in the makefiles were dummy numbers anyway, and the presence of a soname upset a few packaging tools, so it is nicer not to have one. - The cumbersome detour taken on installation (build a libfoo.so.0.0.0 and then override the rule to install foo.so instead) is removed. - Lots of duplicated code simplified.
2008-04-07 16:15:58 +02:00
installdirs: installdirs-lib
plpython: Don't create pgxsdir subdirectory in installdir target As of db23464715f4792298c639153dda7bfd9ad9d602, we don't install anything there anymore from plpython, so we don't need to create the installation directory anymore.
2022-08-31 07:42:01 +02:00
$(MKDIR_P) '$(DESTDIR)$(datadir)/extension' '$(DESTDIR)$(includedir_server)'
Add plpython code.
2001-05-09 21:54:38 +02:00
Create extension infrastructure for the core procedural languages. This mostly just involves creating control, install, and update-from-unpackaged scripts for them. However, I had to adjust plperl and plpython to not share the same support functions between variants, because we can't put the same function into multiple extensions. catversion bump forced due to new contents of pg_pltemplate, and because initdb now installs plpgsql as an extension not a bare language. Add support for regression testing these as extensions not bare languages. Fix a couple of other issues that popped up while testing this: my initial hack at pg_dump binary-upgrade support didn't work right, and we don't want an extra schema permissions test after all. Documentation changes still to come, but I'm committing now to see whether the MSVC build scripts need work (likely they do).
2011-03-05 03:51:14 +01:00
uninstall: uninstall-lib uninstall-data
Add plpython code.
2001-05-09 21:54:38 +02:00
Fix parallel gmake for extension directory addition in PL languages.
2011-03-06 00:32:06 +01:00
install-data: installdirs
Rewrite installation makefile rules without for loops install-sh can install multiple files at once, so for loops are not necessary. This was already changed for the rest of the code some time ago, but pgxs.mk was apparently forgotten, and the obsolete coding style has now been copied to the PLs as well. This also fixes the problem that the for loops in question did not catch errors.
2011-05-01 23:37:07 +02:00
$(INSTALL_DATA) $(addprefix $(srcdir)/, $(DATA)) '$(DESTDIR)$(datadir)/extension/'
Fix out-of-tree build for transform modules. Neither plperl nor plpython installed sufficient header files to permit transform modules to be built out-of-tree using PGXS. Fix that by installing all plperl and plpython header files (other than those with special purposes such as generated data tables), and also install plpython's special .mk file for mangling regression tests. (This commit does not fix the windows install, which does not currently install _any_ plperl or plpython headers.) Also fix the existing transform modules for hstore and ltree so that their cross-module #include directives work as anticipated by commit df163230b9 et seq. This allows them to serve as working examples of how to reference other modules when doing separate out-of-tree builds. Discussion: https://postgr.es/m/87o9ej8bgl.fsf%40news-spur.riddles.org.uk
2018-09-16 19:46:45 +02:00
$(INSTALL_DATA) $(addprefix $(srcdir)/, $(INCS)) '$(DESTDIR)$(includedir_server)'
Create extension infrastructure for the core procedural languages. This mostly just involves creating control, install, and update-from-unpackaged scripts for them. However, I had to adjust plperl and plpython to not share the same support functions between variants, because we can't put the same function into multiple extensions. catversion bump forced due to new contents of pg_pltemplate, and because initdb now installs plpgsql as an extension not a bare language. Add support for regression testing these as extensions not bare languages. Fix a couple of other issues that popped up while testing this: my initial hack at pg_dump binary-upgrade support didn't work right, and we don't want an extra schema permissions test after all. Documentation changes still to come, but I'm committing now to see whether the MSVC build scripts need work (likely they do).
2011-03-05 03:51:14 +01:00
uninstall-data:
rm -f $(addprefix '$(DESTDIR)$(datadir)/extension'/, $(notdir $(DATA)))
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
rm -f $(addprefix '$(DESTDIR)$(includedir_server)'/, plpython.h plpy_util.h)
Create extension infrastructure for the core procedural languages. This mostly just involves creating control, install, and update-from-unpackaged scripts for them. However, I had to adjust plperl and plpython to not share the same support functions between variants, because we can't put the same function into multiple extensions. catversion bump forced due to new contents of pg_pltemplate, and because initdb now installs plpgsql as an extension not a bare language. Add support for regression testing these as extensions not bare languages. Fix a couple of other issues that popped up while testing this: my initial hack at pg_dump binary-upgrade support didn't work right, and we don't want an extra schema permissions test after all. Documentation changes still to come, but I'm committing now to see whether the MSVC build scripts need work (likely they do).
2011-03-05 03:51:14 +01:00
.PHONY: install-data uninstall-data
Provide and use a makefile target to build all generated headers. As of 9.6, pg_regress doesn't build unless storage/lwlocknames.h has been created; but there was nothing forcing that to happen if you just went into src/test/regress/ and built there. We previously had a similar complaint about plpython. To fix in a way that won't break next time we invent a generated header, make src/backend/Makefile expose a phony target for updating all the include files it builds, and invoke that before building pg_regress or plpython. In principle, maybe we ought to invoke that everywhere; but it would add a lot of usually-useless make cycles, so let's just do it in the places where people have complained. I made a couple of cosmetic adjustments in src/backend/Makefile as well, to deal with the generated headers in consistent orders. Michael Paquier and Tom Lane Report: <31398.1467036827@sss.pgh.pa.us> Report: <20150916200959.GB32090@msg.df7cb.de>
2016-07-01 21:08:55 +02:00
check: submake-pg-regress
Allow make check in PL directories Also add make check-world target, and refactor pg_regress invocation code in makefiles a bit.
2011-02-14 20:52:32 +01:00
$(pg_regress_check) $(REGRESS_OPTS) $(REGRESS)
Provide and use a makefile target to build all generated headers. As of 9.6, pg_regress doesn't build unless storage/lwlocknames.h has been created; but there was nothing forcing that to happen if you just went into src/test/regress/ and built there. We previously had a similar complaint about plpython. To fix in a way that won't break next time we invent a generated header, make src/backend/Makefile expose a phony target for updating all the include files it builds, and invoke that before building pg_regress or plpython. In principle, maybe we ought to invoke that everywhere; but it would add a lot of usually-useless make cycles, so let's just do it in the places where people have complained. I made a couple of cosmetic adjustments in src/backend/Makefile as well, to deal with the generated headers in consistent orders. Michael Paquier and Tom Lane Report: <31398.1467036827@sss.pgh.pa.us> Report: <20150916200959.GB32090@msg.df7cb.de>
2016-07-01 21:08:55 +02:00
installcheck: submake-pg-regress
Allow make check in PL directories Also add make check-world target, and refactor pg_regress invocation code in makefiles a bit.
2011-02-14 20:52:32 +01:00
$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
PL/Python: Improve Python 3 regression test setup Currently, we are making mangled copies of plpython/{expected,sql} to plpython/python3/{expected,sql}, and run the tests in plpython/python3. This has the disadvantage that the regression.diffs file, if any, ends up in plpython/python3, which is not the normal location. If we instead make the mangled copies in plpython/{expected,sql}/python3/, we can run the tests from the normal directory, regression.diffs ends up the normal place, and the pg_regress invocation also becomes a lot simpler. It's also more obvious at run time what's going on, because the tests end up being named "python3/something" in the test output.
2012-09-17 04:26:33 +02:00
Convert the existing regression test scripts for the various optional PLs to use the standard pg_regress infrastructure. No changes in the tests themselves. Andrew Dunstan
2005-05-14 19:55:22 +02:00
Provide and use a makefile target to build all generated headers. As of 9.6, pg_regress doesn't build unless storage/lwlocknames.h has been created; but there was nothing forcing that to happen if you just went into src/test/regress/ and built there. We previously had a similar complaint about plpython. To fix in a way that won't break next time we invent a generated header, make src/backend/Makefile expose a phony target for updating all the include files it builds, and invoke that before building pg_regress or plpython. In principle, maybe we ought to invoke that everywhere; but it would add a lot of usually-useless make cycles, so let's just do it in the places where people have complained. I made a couple of cosmetic adjustments in src/backend/Makefile as well, to deal with the generated headers in consistent orders. Michael Paquier and Tom Lane Report: <31398.1467036827@sss.pgh.pa.us> Report: <20150916200959.GB32090@msg.df7cb.de>
2016-07-01 21:08:55 +02:00
.PHONY: submake-pg-regress
Fix YA parallel-make hazard, this one in "make check" in plpython. We have to ensure that submake-generated-headers is finished before the topmost make run launches any child makes. Discussion: https://postgr.es/m/20180411235843.GG32449@paquier.xyz
2018-04-12 16:38:48 +02:00
submake-pg-regress: | submake-generated-headers
Rewrite pg_regress as a C program instead of a shell script. This allows it to be used on Windows without installing mingw (though you do still need 'diff'), and opens the door to future improvements such as message localization. Magnus Hagander and Tom Lane.
2006-07-19 04:37:00 +02:00
$(MAKE) -C $(top_builddir)/src/test/regress pg_regress$(X)
Convert the existing regression test scripts for the various optional PLs to use the standard pg_regress infrastructure. No changes in the tests themselves. Andrew Dunstan
2005-05-14 19:55:22 +02:00
PL/Python custom SPI exceptions This provides a separate exception class for each error code that the backend defines, as well as the ability to get the SQLSTATE from the exception object. Jan Urbański, reviewed by Steve Singer
2011-02-28 17:41:10 +01:00
clean distclean: clean-lib
PL/Python integration: support in create/droplang, add CVS keywords, remove useless files, beat some sense into Makefile. For me it builds and sort of runs, so it's a start.
2001-05-12 03:30:30 +02:00
rm -f $(OBJS)
Allow make check in PL directories Also add make check-world target, and refactor pg_regress invocation code in makefiles a bit.
2011-02-14 20:52:32 +01:00
rm -rf $(pg_regress_clean_files)
Allow plpython to build on Win32. Magnus Hagander
2004-10-06 11:20:41 +02:00
ifeq ($(PORTNAME), win32)
rm -f python${pytverstr}.def
endif
Remove distprep A PostgreSQL release tarball contains a number of prebuilt files, in particular files produced by bison, flex, perl, and well as html and man documentation. We have done this consistent with established practice at the time to not require these tools for building from a tarball. Some of these tools were hard to get, or get the right version of, from time to time, and shipping the prebuilt output was a convenience to users. Now this has at least two problems: One, we have to make the build system(s) work in two modes: Building from a git checkout and building from a tarball. This is pretty complicated, but it works so far for autoconf/make. It does not currently work for meson; you can currently only build with meson from a git checkout. Making meson builds work from a tarball seems very difficult or impossible. One particular problem is that since meson requires a separate build directory, we cannot make the build update files like gram.h in the source tree. So if you were to build from a tarball and update gram.y, you will have a gram.h in the source tree and one in the build tree, but the way things work is that the compiler will always use the one in the source tree. So you cannot, for example, make any gram.y changes when building from a tarball. This seems impossible to fix in a non-horrible way. Second, there is increased interest nowadays in precisely tracking the origin of software. We can reasonably track contributions into the git tree, and users can reasonably track the path from a tarball to packages and downloads and installs. But what happens between the git tree and the tarball is obscure and in some cases non-reproducible. The solution for both of these issues is to get rid of the step that adds prebuilt files to the tarball. The tarball now only contains what is in the git tree (*). Getting the additional build dependencies is no longer a problem nowadays, and the complications to keep these dual build modes working are significant. And of course we want to get the meson build system working universally. This commit removes the make distprep target altogether. The make dist target continues to do its job, it just doesn't call distprep anymore. (*) - The tarball also contains the INSTALL file that is built at make dist time, but not by distprep. This is unchanged for now. The make maintainer-clean target, whose job it is to remove the prebuilt files in addition to what make distclean does, is now just an alias to make distprep. (In practice, it is probably obsolete given that git clean is available.) The following programs are now hard build requirements in configure (they were already required by meson.build): - bison - flex - perl Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/flat/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org
2023-11-06 14:51:52 +01:00
rm -f spiexceptions.h
Add plpython code.
2001-05-09 21:54:38 +02:00
Make distprep and *clean build targets recurse into all subdirectories. Certain subdirectories do not get built if corresponding options are not selected at configure time. However, "make distprep" should visit such directories anyway, so that constructing derived files to be included in the tarball happens without requiring all configure options to be given in the tarball build script. Likewise, it's better if cleanup actions unconditionally visit all directories (for example, this ensures proper cleanup if someone has done a manual make in such a subdirectory). To handle this, set up a convention that subdirectories that are conditionally included in SUBDIRS should be added to ALWAYS_SUBDIRS instead when they are excluded. Back-patch to 9.1, so that plpython's spiexceptions.h will get provided in 9.1 tarballs. There don't appear to be any instances where distprep actions got missed in previous releases, and anyway this fix requires gmake 3.80 so we don't want to apply it before 9.1.
2011-07-03 19:55:02 +02:00
# Force this dependency to be known even without dependency info built:
PL/Python: One more file renaming fix to unbreak the build
2011-12-18 21:34:53 +01:00
plpy_plpymodule.o: spiexceptions.h
Make distprep and *clean build targets recurse into all subdirectories. Certain subdirectories do not get built if corresponding options are not selected at configure time. However, "make distprep" should visit such directories anyway, so that constructing derived files to be included in the tarball happens without requiring all configure options to be given in the tarball build script. Likewise, it's better if cleanup actions unconditionally visit all directories (for example, this ensures proper cleanup if someone has done a manual make in such a subdirectory). To handle this, set up a convention that subdirectories that are conditionally included in SUBDIRS should be added to ALWAYS_SUBDIRS instead when they are excluded. Back-patch to 9.1, so that plpython's spiexceptions.h will get provided in 9.1 tarballs. There don't appear to be any instances where distprep actions got missed in previous releases, and anyway this fix requires gmake 3.80 so we don't want to apply it before 9.1.
2011-07-03 19:55:02 +02:00
spiexceptions.h: $(top_srcdir)/src/backend/utils/errcodes.txt generate-spiexceptions.pl
$(PERL) $(srcdir)/generate-spiexceptions.pl $< > $@