1996-10-27 10:55:05 +01:00
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
#
|
2002-03-22 22:34:44 +01:00
|
|
|
# Makefile for backend/catalog
|
1996-10-27 10:55:05 +01:00
|
|
|
#
|
2010-09-20 22:08:53 +02:00
|
|
|
# src/backend/catalog/Makefile
|
1996-10-27 10:55:05 +01:00
|
|
|
#
|
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
2000-07-06 23:33:45 +02:00
|
|
|
subdir = src/backend/catalog
|
|
|
|
top_builddir = ../../..
|
2000-08-31 18:12:35 +02:00
|
|
|
include $(top_builddir)/src/Makefile.global
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2002-07-12 20:43:19 +02:00
|
|
|
OBJS = catalog.o dependency.o heap.o index.o indexing.o namespace.o aclchk.o \
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
objectaccess.o objectaddress.o partition.o pg_aggregate.o pg_collation.o \
|
2013-03-07 02:52:06 +01:00
|
|
|
pg_constraint.o pg_conversion.o \
|
2010-08-27 13:47:41 +02:00
|
|
|
pg_depend.o pg_enum.o pg_inherits.o pg_largeobject.o pg_namespace.o \
|
2017-01-19 18:00:00 +01:00
|
|
|
pg_operator.o pg_proc.o pg_publication.o pg_range.o \
|
|
|
|
pg_db_role_setting.o pg_shdepend.o pg_subscription.o pg_type.o \
|
|
|
|
storage.o toasting.o
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2006-02-12 04:22:21 +01:00
|
|
|
BKIFILES = postgres.bki postgres.description postgres.shdescription
|
2000-06-05 09:16:13 +02:00
|
|
|
|
2008-02-19 11:30:09 +01:00
|
|
|
include $(top_srcdir)/src/backend/common.mk
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2010-01-05 02:06:57 +01:00
|
|
|
all: $(BKIFILES) schemapg.h
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2001-06-12 07:55:50 +02:00
|
|
|
# Note: there are some undocumented dependencies on the ordering in which
|
|
|
|
# the catalog header files are assembled into postgres.bki. In particular,
|
2006-07-31 03:16:38 +02:00
|
|
|
# indexing.h had better be last, and toasting.h just before it.
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2007-02-09 16:56:00 +01:00
|
|
|
POSTGRES_BKI_SRCS = $(addprefix $(top_srcdir)/src/include/catalog/,\
|
2014-12-23 19:35:49 +01:00
|
|
|
pg_proc.h pg_type.h pg_attribute.h pg_class.h \
|
2006-12-23 01:43:13 +01:00
|
|
|
pg_attrdef.h pg_constraint.h pg_inherits.h pg_index.h pg_operator.h \
|
|
|
|
pg_opfamily.h pg_opclass.h pg_am.h pg_amop.h pg_amproc.h \
|
2009-12-11 04:34:57 +01:00
|
|
|
pg_language.h pg_largeobject_metadata.h pg_largeobject.h pg_aggregate.h \
|
2012-07-18 16:16:16 +02:00
|
|
|
pg_statistic.h pg_rewrite.h pg_trigger.h pg_event_trigger.h pg_description.h \
|
2009-12-11 04:34:57 +01:00
|
|
|
pg_cast.h pg_enum.h pg_namespace.h pg_conversion.h pg_depend.h \
|
2009-10-08 00:14:26 +02:00
|
|
|
pg_database.h pg_db_role_setting.h pg_tablespace.h pg_pltemplate.h \
|
2006-02-12 04:22:21 +01:00
|
|
|
pg_authid.h pg_auth_members.h pg_shdepend.h pg_shdescription.h \
|
2007-08-21 03:11:32 +02:00
|
|
|
pg_ts_config.h pg_ts_config_map.h pg_ts_dict.h \
|
2011-02-08 22:08:41 +01:00
|
|
|
pg_ts_parser.h pg_ts_template.h pg_extension.h \
|
2008-12-19 17:25:19 +01:00
|
|
|
pg_foreign_data_wrapper.h pg_foreign_server.h pg_user_mapping.h \
|
Introduce replication progress tracking infrastructure.
When implementing a replication solution ontop of logical decoding, two
related problems exist:
* How to safely keep track of replication progress
* How to change replication behavior, based on the origin of a row;
e.g. to avoid loops in bi-directional replication setups
The solution to these problems, as implemented here, consist out of
three parts:
1) 'replication origins', which identify nodes in a replication setup.
2) 'replication progress tracking', which remembers, for each
replication origin, how far replay has progressed in a efficient and
crash safe manner.
3) The ability to filter out changes performed on the behest of a
replication origin during logical decoding; this allows complex
replication topologies. E.g. by filtering all replayed changes out.
Most of this could also be implemented in "userspace", e.g. by inserting
additional rows contain origin information, but that ends up being much
less efficient and more complicated. We don't want to require various
replication solutions to reimplement logic for this independently. The
infrastructure is intended to be generic enough to be reusable.
This infrastructure also replaces the 'nodeid' infrastructure of commit
timestamps. It is intended to provide all the former capabilities,
except that there's only 2^16 different origins; but now they integrate
with logical decoding. Additionally more functionality is accessible via
SQL. Since the commit timestamp infrastructure has also been introduced
in 9.5 (commit 73c986add) changing the API is not a problem.
For now the number of origins for which the replication progress can be
tracked simultaneously is determined by the max_replication_slots
GUC. That GUC is not a perfect match to configure this, but there
doesn't seem to be sufficient reason to introduce a separate new one.
Bumps both catversion and wal page magic.
Author: Andres Freund, with contributions from Petr Jelinek and Craig Ringer
Reviewed-By: Heikki Linnakangas, Petr Jelinek, Robert Haas, Steve Singer
Discussion: 20150216002155.GI15326@awork2.anarazel.de,
20140923182422.GA15776@alap3.anarazel.de,
20131114172632.GE7522@alap2.anarazel.de
2015-04-29 19:30:53 +02:00
|
|
|
pg_foreign_table.h pg_policy.h pg_replication_origin.h \
|
2016-04-07 03:45:32 +02:00
|
|
|
pg_default_acl.h pg_init_privs.h pg_seclabel.h pg_shseclabel.h \
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
pg_collation.h pg_partitioned_table.h pg_range.h pg_transform.h \
|
2017-01-19 18:00:00 +01:00
|
|
|
pg_sequence.h pg_publication.h pg_publication_rel.h pg_subscription.h \
|
2017-03-23 13:36:36 +01:00
|
|
|
pg_subscription_rel.h toasting.h indexing.h \
|
Redesign tablesample method API, and do extensive code review.
The original implementation of TABLESAMPLE modeled the tablesample method
API on index access methods, which wasn't a good choice because, without
specialized DDL commands, there's no way to build an extension that can
implement a TSM. (Raw inserts into system catalogs are not an acceptable
thing to do, because we can't undo them during DROP EXTENSION, nor will
pg_upgrade behave sanely.) Instead adopt an API more like procedural
language handlers or foreign data wrappers, wherein the only SQL-level
support object needed is a single handler function identified by having
a special return type. This lets us get rid of the supporting catalog
altogether, so that no custom DDL support is needed for the feature.
Adjust the API so that it can support non-constant tablesample arguments
(the original coding assumed we could evaluate the argument expressions at
ExecInitSampleScan time, which is undesirable even if it weren't outright
unsafe), and discourage sampling methods from looking at invisible tuples.
Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable
within and across queries, as required by the SQL standard, and deal more
honestly with methods that can't support that requirement.
Make a full code-review pass over the tablesample additions, and fix
assorted bugs, omissions, infelicities, and cosmetic issues (such as
failure to put the added code stanzas in a consistent ordering).
Improve EXPLAIN's output of tablesample plans, too.
Back-patch to 9.5 so that we don't have to support the original API
in production.
2015-07-25 20:39:00 +02:00
|
|
|
toasting.h indexing.h \
|
2000-07-06 23:33:45 +02:00
|
|
|
)
|
|
|
|
|
2010-01-05 02:06:57 +01:00
|
|
|
# location of Catalog.pm
|
|
|
|
catalogdir = $(top_srcdir)/src/backend/catalog
|
|
|
|
|
|
|
|
# locations of headers that genbki.pl needs to read
|
|
|
|
pg_includes = -I$(top_srcdir)/src/include/catalog -I$(top_builddir)/src/include/catalog
|
2000-07-06 23:33:45 +02:00
|
|
|
|
2003-08-01 18:12:32 +02:00
|
|
|
# see explanation in ../parser/Makefile
|
|
|
|
postgres.description: postgres.bki ;
|
|
|
|
|
2006-02-12 04:22:21 +01:00
|
|
|
postgres.shdescription: postgres.bki ;
|
|
|
|
|
2010-01-05 02:06:57 +01:00
|
|
|
schemapg.h: postgres.bki ;
|
|
|
|
|
2012-05-09 19:45:56 +02:00
|
|
|
# Technically, this should depend on Makefile.global, but then
|
|
|
|
# postgres.bki would need to be rebuilt after every configure run,
|
|
|
|
# even in distribution tarballs. So this is cheating a bit, but it
|
|
|
|
# will achieve the goal of updating the version number when it
|
|
|
|
# changes.
|
2013-09-11 20:34:28 +02:00
|
|
|
postgres.bki: genbki.pl Catalog.pm $(POSTGRES_BKI_SRCS) $(top_srcdir)/configure $(top_srcdir)/src/include/catalog/duplicate_oids
|
2013-10-11 04:42:11 +02:00
|
|
|
cd $(top_srcdir)/src/include/catalog && $(PERL) ./duplicate_oids
|
2010-01-06 20:56:29 +01:00
|
|
|
$(PERL) -I $(catalogdir) $< $(pg_includes) --set-version=$(MAJORVERSION) $(POSTGRES_BKI_SRCS)
|
2000-07-06 23:33:45 +02:00
|
|
|
|
2002-12-14 01:24:35 +01:00
|
|
|
.PHONY: install-data
|
|
|
|
install-data: $(BKIFILES) installdirs
|
2010-05-13 13:49:48 +02:00
|
|
|
$(INSTALL_DATA) $(call vpathsearch,postgres.bki) '$(DESTDIR)$(datadir)/postgres.bki'
|
|
|
|
$(INSTALL_DATA) $(call vpathsearch,postgres.description) '$(DESTDIR)$(datadir)/postgres.description'
|
|
|
|
$(INSTALL_DATA) $(call vpathsearch,postgres.shdescription) '$(DESTDIR)$(datadir)/postgres.shdescription'
|
2005-12-09 22:19:36 +01:00
|
|
|
$(INSTALL_DATA) $(srcdir)/system_views.sql '$(DESTDIR)$(datadir)/system_views.sql'
|
|
|
|
$(INSTALL_DATA) $(srcdir)/information_schema.sql '$(DESTDIR)$(datadir)/information_schema.sql'
|
|
|
|
$(INSTALL_DATA) $(srcdir)/sql_features.txt '$(DESTDIR)$(datadir)/sql_features.txt'
|
2000-07-06 23:33:45 +02:00
|
|
|
|
|
|
|
installdirs:
|
2009-08-27 00:24:44 +02:00
|
|
|
$(MKDIR_P) '$(DESTDIR)$(datadir)'
|
2000-07-06 23:33:45 +02:00
|
|
|
|
2002-12-14 01:24:35 +01:00
|
|
|
.PHONY: uninstall-data
|
|
|
|
uninstall-data:
|
2005-12-09 22:19:36 +01:00
|
|
|
rm -f $(addprefix '$(DESTDIR)$(datadir)'/, $(BKIFILES) system_views.sql information_schema.sql sql_features.txt)
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2010-01-05 02:06:57 +01:00
|
|
|
# postgres.bki, postgres.description, postgres.shdescription, and schemapg.h
|
|
|
|
# are in the distribution tarball, so they are not cleaned here.
|
2004-06-18 08:14:31 +02:00
|
|
|
clean:
|
2010-01-05 02:06:57 +01:00
|
|
|
|
|
|
|
maintainer-clean: clean
|
2008-02-19 11:30:09 +01:00
|
|
|
rm -f $(BKIFILES)
|