2000-01-05 18:31:08 +01:00
|
|
|
VACUUM;
|
|
|
|
|
--
|
|
|
|
|
-- sanity check, if we don't have indices the test will take years to
|
2006-08-06 06:35:21 +02:00
|
|
|
-- complete. But skip TOAST relations (since they will have varying
|
|
|
|
|
-- names depending on the current OID counter) as well as temp tables
|
|
|
|
|
-- of other backends (to avoid timing-dependent behavior).
|
2000-01-05 18:31:08 +01:00
|
|
|
--
|
2013-10-26 17:24:04 +02:00
|
|
|
-- temporarily disable fancy output, so catalog changes create less diff noise
|
|
|
|
|
\a\t
|
2000-01-05 18:31:08 +01:00
|
|
|
SELECT relname, relhasindex
|
2006-08-06 06:35:21 +02:00
|
|
|
FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = relnamespace
|
2017-03-10 19:15:47 +01:00
|
|
|
WHERE relkind IN ('r', 'p') AND (nspname ~ '^pg_temp_') IS NOT TRUE
|
1997-04-06 08:07:13 +02:00
|
|
|
ORDER BY relname;
|
2013-10-26 17:24:04 +02:00
|
|
|
a|f
|
|
|
|
|
a_star|f
|
|
|
|
|
aggtest|f
|
|
|
|
|
array_index_op_test|t
|
|
|
|
|
array_op_test|f
|
|
|
|
|
b|f
|
|
|
|
|
b_star|f
|
Remove ruleutils.c's special case for BIT [VARYING] literals.
Up to now, get_const_expr() insisted on prefixing BIT and VARBIT
literals with 'B'. That's not really necessary, because we always
append explicit-cast syntax to identify the constant's type.
Moreover, it's subtly wrong for VARBIT, because the parser will
interpret B'...' as '...'::"bit"; see make_const() which explicitly
assigns type BITOID for a T_BitString literal. So what had been
a simple VARBIT literal is reconstructed as ('...'::"bit")::varbit,
which is not the same thing, at least not before constant folding.
This results in odd differences after dump/restore, as complained
of by the patch submitter, and it could result in actual failures in
partitioning or inheritance DDL operations (see commit 542320c2b,
which repaired similar misbehaviors for some other data types).
Fixing it is pretty easy: just remove the special case and let the
default code path handle these types. We could have kept the special
case for BIT only, but there seems little point in that.
Like the previous patch, I judge that back-patching this into stable
branches wouldn't be a good idea. However, it seems not quite too
late for v11, so let's fix it there.
Paul Guo, reviewed by Davy Machado and John Naylor, minor adjustments
by me
Discussion: https://postgr.es/m/CABQrizdTra=2JEqA6+Ms1D1k1Kqw+aiBBhC9TreuZRX2JzxLAA@mail.gmail.com
2018-09-11 22:32:12 +02:00
|
|
|
bit_defaults|f
|
2013-10-26 17:24:04 +02:00
|
|
|
box_tbl|f
|
|
|
|
|
bprime|f
|
|
|
|
|
bt_f8_heap|t
|
|
|
|
|
bt_i4_heap|t
|
|
|
|
|
bt_name_heap|t
|
|
|
|
|
bt_txt_heap|t
|
|
|
|
|
c|f
|
|
|
|
|
c_star|f
|
|
|
|
|
char_tbl|f
|
|
|
|
|
check2_tbl|f
|
|
|
|
|
check_tbl|f
|
|
|
|
|
circle_tbl|t
|
|
|
|
|
city|f
|
|
|
|
|
copy_tbl|f
|
|
|
|
|
d|f
|
|
|
|
|
d_star|f
|
|
|
|
|
date_tbl|f
|
|
|
|
|
default_tbl|f
|
|
|
|
|
defaultexpr_tbl|f
|
|
|
|
|
dept|f
|
|
|
|
|
dupindexcols|t
|
|
|
|
|
e_star|f
|
|
|
|
|
emp|f
|
|
|
|
|
equipment_r|f
|
2018-11-27 19:07:03 +01:00
|
|
|
extra_wide_table|f
|
2013-10-26 17:24:04 +02:00
|
|
|
f_star|f
|
2016-04-14 05:33:31 +02:00
|
|
|
fast_emp4000|t
|
2013-10-26 17:24:04 +02:00
|
|
|
float4_tbl|f
|
|
|
|
|
float8_tbl|f
|
|
|
|
|
func_index_heap|t
|
|
|
|
|
hash_f8_heap|t
|
|
|
|
|
hash_i4_heap|t
|
|
|
|
|
hash_name_heap|t
|
|
|
|
|
hash_txt_heap|t
|
|
|
|
|
hobbies_r|f
|
|
|
|
|
ihighway|t
|
|
|
|
|
inet_tbl|f
|
|
|
|
|
insert_tbl|f
|
|
|
|
|
int2_tbl|f
|
|
|
|
|
int4_tbl|f
|
|
|
|
|
int8_tbl|f
|
|
|
|
|
interval_tbl|f
|
Fix two bugs in merging of inherited CHECK constraints.
Historically, we've allowed users to add a CHECK constraint to a child
table and then add an identical CHECK constraint to the parent. This
results in "merging" the two constraints so that the pre-existing
child constraint ends up with both conislocal = true and coninhcount > 0.
However, if you tried to do it in the other order, you got a duplicate
constraint error. This is problematic for pg_dump, which needs to issue
separated ADD CONSTRAINT commands in some cases, but has no good way to
ensure that the constraints will be added in the required order.
And it's more than a bit arbitrary, too. The goal of complaining about
duplicated ADD CONSTRAINT commands can be served if we reject the case of
adding a constraint when the existing one already has conislocal = true;
but if it has conislocal = false, let's just make the ADD CONSTRAINT set
conislocal = true. In this way, either order of adding the constraints
has the same end result.
Another problem was that the code allowed creation of a parent constraint
marked convalidated that is merged with a child constraint that is
!convalidated. In this case, an inheritance scan of the parent table could
emit some rows violating the constraint condition, which would be an
unexpected result given the marking of the parent constraint as validated.
Hence, forbid merging of constraints in this case. (Note: valid child and
not-valid parent seems fine, so continue to allow that.)
Per report from Benedikt Grundmann. Back-patch to 9.2 where we introduced
possibly-not-valid check constraints. The second bug obviously doesn't
apply before that, and I think the first doesn't either, because pg_dump
only gets into this situation when dealing with not-valid constraints.
Report: <CADbMkNPT-Jz5PRSQ4RbUASYAjocV_KHUWapR%2Bg8fNvhUAyRpxA%40mail.gmail.com>
Discussion: <22108.1475874586@sss.pgh.pa.us>
2016-10-09 01:29:27 +02:00
|
|
|
invalid_check_con|f
|
|
|
|
|
invalid_check_con_child|f
|
2013-10-26 17:24:04 +02:00
|
|
|
iportaltest|f
|
|
|
|
|
kd_point_tbl|t
|
|
|
|
|
line_tbl|f
|
|
|
|
|
log_table|f
|
|
|
|
|
lseg_tbl|f
|
|
|
|
|
main_table|f
|
2017-03-07 17:32:33 +01:00
|
|
|
mlparted|f
|
|
|
|
|
mlparted1|f
|
|
|
|
|
mlparted11|f
|
|
|
|
|
mlparted12|f
|
|
|
|
|
mlparted2|f
|
|
|
|
|
mlparted3|f
|
|
|
|
|
mlparted4|f
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
mlparted_def|f
|
|
|
|
|
mlparted_def1|f
|
|
|
|
|
mlparted_def2|f
|
|
|
|
|
mlparted_defd|f
|
2013-10-26 17:24:04 +02:00
|
|
|
money_data|f
|
|
|
|
|
num_data|f
|
|
|
|
|
num_exp_add|t
|
|
|
|
|
num_exp_div|t
|
|
|
|
|
num_exp_ln|t
|
|
|
|
|
num_exp_log10|t
|
|
|
|
|
num_exp_mul|t
|
|
|
|
|
num_exp_power_10_ln|t
|
|
|
|
|
num_exp_sqrt|t
|
|
|
|
|
num_exp_sub|t
|
|
|
|
|
num_input_test|f
|
|
|
|
|
num_result|f
|
Allow numeric scale to be negative or greater than precision.
Formerly, when specifying NUMERIC(precision, scale), the scale had to
be in the range [0, precision], which was per SQL spec. This commit
extends the range of allowed scales to [-1000, 1000], independent of
the precision (whose valid range remains [1, 1000]).
A negative scale implies rounding before the decimal point. For
example, a column might be declared with a scale of -3 to round values
to the nearest thousand. Note that the display scale remains
non-negative, so in this case the display scale will be zero, and all
digits before the decimal point will be displayed.
A scale greater than the precision supports fractional values with
zeros immediately after the decimal point.
Take the opportunity to tidy up the code that packs, unpacks and
validates the contents of a typmod integer, encapsulating it in a
small set of new inline functions.
Bump the catversion because the allowed contents of atttypmod have
changed for numeric columns. This isn't a change that requires a
re-initdb, but negative scale values in the typmod would confuse old
backends.
Dean Rasheed, with additional improvements by Tom Lane. Reviewed by
Tom Lane.
Discussion: https://postgr.es/m/CAEZATCWdNLgpKihmURF8nfofP0RFtAKJ7ktY6GcZOPnMfUoRqA@mail.gmail.com
2021-07-26 15:13:47 +02:00
|
|
|
num_typemod_test|f
|
Multirange datatypes
Multiranges are basically sorted arrays of non-overlapping ranges with
set-theoretic operations defined over them.
Since v14, each range type automatically gets a corresponding multirange
datatype. There are both manual and automatic mechanisms for naming multirange
types. Once can specify multirange type name using multirange_type_name
attribute in CREATE TYPE. Otherwise, a multirange type name is generated
automatically. If the range type name contains "range" then we change that to
"multirange". Otherwise, we add "_multirange" to the end.
Implementation of multiranges comes with a space-efficient internal
representation format, which evades extra paddings and duplicated storage of
oids. Altogether this format allows fetching a particular range by its index
in O(n).
Statistic gathering and selectivity estimation are implemented for multiranges.
For this purpose, stored multirange is approximated as union range without gaps.
This field will likely need improvements in the future.
Catversion is bumped.
Discussion: https://postgr.es/m/CALNJ-vSUpQ_Y%3DjXvTxt1VYFztaBSsWVXeF1y6gTYQ4bOiWDLgQ%40mail.gmail.com
Discussion: https://postgr.es/m/a0b8026459d1e6167933be2104a6174e7d40d0ab.camel%40j-davis.com#fe7218c83b08068bfffb0c5293eceda0
Author: Paul Jungwirth, revised by me
Reviewed-by: David Fetter, Corey Huinker, Jeff Davis, Pavel Stehule
Reviewed-by: Alvaro Herrera, Tom Lane, Isaac Morland, David G. Johnston
Reviewed-by: Zhihong Yu, Alexander Korotkov
2020-12-20 05:20:33 +01:00
|
|
|
nummultirange_test|t
|
2020-01-31 23:03:55 +01:00
|
|
|
numrange_test|t
|
2013-10-26 17:24:04 +02:00
|
|
|
onek|t
|
|
|
|
|
onek2|t
|
|
|
|
|
path_tbl|f
|
|
|
|
|
person|f
|
2017-04-28 02:14:39 +02:00
|
|
|
persons|f
|
|
|
|
|
persons2|t
|
|
|
|
|
persons3|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_aggregate|t
|
|
|
|
|
pg_am|t
|
|
|
|
|
pg_amop|t
|
|
|
|
|
pg_amproc|t
|
|
|
|
|
pg_attrdef|t
|
|
|
|
|
pg_attribute|t
|
|
|
|
|
pg_auth_members|t
|
|
|
|
|
pg_authid|t
|
|
|
|
|
pg_cast|t
|
|
|
|
|
pg_class|t
|
|
|
|
|
pg_collation|t
|
|
|
|
|
pg_constraint|t
|
|
|
|
|
pg_conversion|t
|
|
|
|
|
pg_database|t
|
|
|
|
|
pg_db_role_setting|t
|
|
|
|
|
pg_default_acl|t
|
|
|
|
|
pg_depend|t
|
|
|
|
|
pg_description|t
|
|
|
|
|
pg_enum|t
|
|
|
|
|
pg_event_trigger|t
|
|
|
|
|
pg_extension|t
|
|
|
|
|
pg_foreign_data_wrapper|t
|
|
|
|
|
pg_foreign_server|t
|
|
|
|
|
pg_foreign_table|t
|
|
|
|
|
pg_index|t
|
|
|
|
|
pg_inherits|t
|
2016-04-07 03:45:32 +02:00
|
|
|
pg_init_privs|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_language|t
|
|
|
|
|
pg_largeobject|t
|
|
|
|
|
pg_largeobject_metadata|t
|
|
|
|
|
pg_namespace|t
|
|
|
|
|
pg_opclass|t
|
|
|
|
|
pg_operator|t
|
|
|
|
|
pg_opfamily|t
|
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_partitioned_table|t
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
pg_policy|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_proc|t
|
2017-01-19 18:00:00 +01:00
|
|
|
pg_publication|t
|
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
|
|
|
pg_publication_namespace|t
|
2017-01-19 18:00:00 +01:00
|
|
|
pg_publication_rel|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_range|t
|
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_replication_origin|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_rewrite|t
|
|
|
|
|
pg_seclabel|t
|
2016-12-20 18:00:00 +01:00
|
|
|
pg_sequence|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_shdepend|t
|
|
|
|
|
pg_shdescription|t
|
|
|
|
|
pg_shseclabel|t
|
|
|
|
|
pg_statistic|t
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
pg_statistic_ext|t
|
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
|
|
|
pg_statistic_ext_data|t
|
2017-01-19 18:00:00 +01:00
|
|
|
pg_subscription|t
|
2017-03-23 13:36:36 +01:00
|
|
|
pg_subscription_rel|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_tablespace|t
|
2015-04-26 16:33:14 +02:00
|
|
|
pg_transform|t
|
2013-10-26 17:24:04 +02:00
|
|
|
pg_trigger|t
|
|
|
|
|
pg_ts_config|t
|
|
|
|
|
pg_ts_config_map|t
|
|
|
|
|
pg_ts_dict|t
|
|
|
|
|
pg_ts_parser|t
|
|
|
|
|
pg_ts_template|t
|
|
|
|
|
pg_type|t
|
|
|
|
|
pg_user_mapping|t
|
|
|
|
|
point_tbl|t
|
|
|
|
|
polygon_tbl|t
|
2017-03-21 14:23:10 +01:00
|
|
|
quad_box_tbl|t
|
2019-07-14 13:57:53 +02:00
|
|
|
quad_box_tbl_ord_seq1|f
|
|
|
|
|
quad_box_tbl_ord_seq2|f
|
2013-10-26 17:24:04 +02:00
|
|
|
quad_point_tbl|t
|
2017-12-25 16:59:38 +01:00
|
|
|
quad_poly_tbl|t
|
2013-10-26 17:24:04 +02:00
|
|
|
radix_text_tbl|t
|
|
|
|
|
ramp|f
|
|
|
|
|
real_city|f
|
Multirange datatypes
Multiranges are basically sorted arrays of non-overlapping ranges with
set-theoretic operations defined over them.
Since v14, each range type automatically gets a corresponding multirange
datatype. There are both manual and automatic mechanisms for naming multirange
types. Once can specify multirange type name using multirange_type_name
attribute in CREATE TYPE. Otherwise, a multirange type name is generated
automatically. If the range type name contains "range" then we change that to
"multirange". Otherwise, we add "_multirange" to the end.
Implementation of multiranges comes with a space-efficient internal
representation format, which evades extra paddings and duplicated storage of
oids. Altogether this format allows fetching a particular range by its index
in O(n).
Statistic gathering and selectivity estimation are implemented for multiranges.
For this purpose, stored multirange is approximated as union range without gaps.
This field will likely need improvements in the future.
Catversion is bumped.
Discussion: https://postgr.es/m/CALNJ-vSUpQ_Y%3DjXvTxt1VYFztaBSsWVXeF1y6gTYQ4bOiWDLgQ%40mail.gmail.com
Discussion: https://postgr.es/m/a0b8026459d1e6167933be2104a6174e7d40d0ab.camel%40j-davis.com#fe7218c83b08068bfffb0c5293eceda0
Author: Paul Jungwirth, revised by me
Reviewed-by: David Fetter, Corey Huinker, Jeff Davis, Pavel Stehule
Reviewed-by: Alvaro Herrera, Tom Lane, Isaac Morland, David G. Johnston
Reviewed-by: Zhihong Yu, Alexander Korotkov
2020-12-20 05:20:33 +01:00
|
|
|
reservations|f
|
2013-10-26 17:24:04 +02:00
|
|
|
road|t
|
|
|
|
|
shighway|t
|
|
|
|
|
slow_emp4000|f
|
|
|
|
|
sql_features|f
|
|
|
|
|
sql_implementation_info|f
|
|
|
|
|
sql_parts|f
|
|
|
|
|
sql_sizing|f
|
|
|
|
|
stud_emp|f
|
|
|
|
|
student|f
|
Add table to regression tests for binary-compatibility checks in pg_upgrade
This commit adds to the main regression test suite a table with all
the in-core data types (some exceptions apply). This table is not
dropped, so as pg_upgrade would be able to check the binary
compatibility of the types tracked in the table. If a new type is added
in core, this part of the tests would need a refresh but the tests are
designed to fail if that were to happen.
As this is useful for upgrades and that these rely on the objects
created in the regression test suite of the old version upgraded from,
a backpatch down to 12 is done, which is the last point where a binary
incompatible change has been done (7c15cef). This will hopefully be
enough to find out if something gets broken during the development of a
new version of Postgres, so as it is possible to take actions in
pg_upgrade itself in this case (like 0ccfc28 for sql_identifier).
An area that is not covered yet is related to external modules, which
may create their own types. The testing infrastructure of pg_upgrade is
not integrated yet with the external modules stored in core
(src/test/modules/ or contrib/, all use the same database name for their
tests so there would be an overlap). This could be improved in the
future.
Author: Justin Pryzby
Reviewed-by: Jacob Champion, Peter Eisentraut, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/20201206180248.GI24052@telsasoft.com
Backpatch-through: 12
2021-11-18 02:37:15 +01:00
|
|
|
tab_core_types|f
|
tableam: introduce table AM infrastructure.
This introduces the concept of table access methods, i.e. CREATE
ACCESS METHOD ... TYPE TABLE and
CREATE TABLE ... USING (storage-engine).
No table access functionality is delegated to table AMs as of this
commit, that'll be done in following commits.
Subsequent commits will incrementally abstract table access
functionality to be routed through table access methods. That change
is too large to be reviewed & committed at once, so it'll be done
incrementally.
Docs will be updated at the end, as adding them incrementally would
likely make them less coherent, and definitely is a lot more work,
without a lot of benefit.
Table access methods are specified similar to index access methods,
i.e. pg_am.amhandler returns, as INTERNAL, a pointer to a struct with
callbacks. In contrast to index AMs that struct needs to live as long
as a backend, typically that's achieved by just returning a pointer to
a constant struct.
Psql's \d+ now displays a table's access method. That can be disabled
with HIDE_TABLEAM=true, which is mainly useful so regression tests can
be run against different AMs. It's quite possible that this behaviour
still needs to be fine tuned.
For now it's not allowed to set a table AM for a partitioned table, as
we've not resolved how partitions would inherit that. Disallowing
allows us to introduce, if we decide that's the way forward, such a
behaviour without a compatibility break.
Catversion bumped, to add the heap table AM and references to it.
Author: Haribabu Kommi, Andres Freund, Alvaro Herrera, Dimitri Golgov and others
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://postgr.es/m/20190107235616.6lur25ph22u5u5av@alap3.anarazel.de
https://postgr.es/m/20190304234700.w5tmhducs5wxgzls@alap3.anarazel.de
2019-03-06 18:54:38 +01:00
|
|
|
tableam_parted_a_heap2|f
|
|
|
|
|
tableam_parted_b_heap2|f
|
|
|
|
|
tableam_parted_c_heap2|f
|
|
|
|
|
tableam_parted_d_heap2|f
|
|
|
|
|
tableam_parted_heap2|f
|
|
|
|
|
tableam_tbl_heap2|f
|
|
|
|
|
tableam_tblas_heap2|f
|
Adjust INCLUDE index truncation comments and code.
Add several assertions that ensure that we're dealing with a pivot tuple
without non-key attributes where that's expected. Also, remove the
assertion within _bt_isequal(), restoring the v10 function signature. A
similar check will be performed for the page highkey within
_bt_moveright() in most cases. Also avoid dropping all objects within
regression tests, to increase pg_dump test coverage for INCLUDE indexes.
Rather than using infrastructure that's generally intended to be used
with reference counted heap tuple descriptors during truncation, use the
same function that was introduced to store flat TupleDescs in shared
memory (we use a temp palloc'd buffer). This isn't strictly necessary,
but seems more future-proof than the old approach. It also lets us
avoid including rel.h within indextuple.c, which was arguably a
modularity violation. Also, we now call index_deform_tuple() with the
truncated TupleDesc, not the source TupleDesc, since that's more robust,
and saves a few cycles.
In passing, fix a memory leak by pfree'ing truncated pivot tuple memory
during CREATE INDEX. Also pfree during a page split, just to be
consistent.
Refactor _bt_check_natts() to be more readable.
Author: Peter Geoghegan with some editorization by me
Reviewed by: Alexander Korotkov, Teodor Sigaev
Discussion: https://www.postgresql.org/message-id/CAH2-Wz%3DkCWuXeMrBCopC-tFs3FbiVxQNjjgNKdG2sHxZ5k2y3w%40mail.gmail.com
2018-04-19 07:45:58 +02:00
|
|
|
tbl_include_box|t
|
|
|
|
|
tbl_include_box_pk|f
|
|
|
|
|
tbl_include_pk|t
|
|
|
|
|
tbl_include_reg|t
|
|
|
|
|
tbl_include_unique1|t
|
|
|
|
|
tbl_include_unique2|f
|
2013-10-26 17:24:04 +02:00
|
|
|
tenk1|t
|
|
|
|
|
tenk2|t
|
|
|
|
|
test_range_excl|t
|
|
|
|
|
test_range_gist|t
|
|
|
|
|
test_range_spgist|t
|
|
|
|
|
test_tsvector|f
|
2014-03-24 01:18:06 +01:00
|
|
|
testjsonb|f
|
2013-10-26 17:24:04 +02:00
|
|
|
text_tbl|f
|
2020-01-31 23:03:55 +01:00
|
|
|
textrange_test|t
|
2013-10-26 17:24:04 +02:00
|
|
|
time_tbl|f
|
|
|
|
|
timestamp_tbl|f
|
|
|
|
|
timestamptz_tbl|f
|
|
|
|
|
timetz_tbl|f
|
Re-order some regression test scripts for more parallelism.
Move the strings, numerology, insert, insert_conflict, select and
errors tests to be parts of nearby parallel groups, instead of
executing by themselves. (Moving "select" required adjusting the
constraints test, which uses a table named "tmp" as select also
does. There don't seem to be any other conflicts.)
Move psql and stats_ext to the next parallel group, where the rules
test also has a long runtime. To make it safe to run stats_ext in
parallel with rules, I adjusted the latter to only dump views/rules
from the pg_catalog and public schemas, which was what it was doing
anyway. stats_ext makes some views in a transient schema, which now
will not affect rules.
Reorder serial_schedule to match parallel_schedule.
Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us
2019-04-12 00:16:50 +02:00
|
|
|
tmp|f
|
2020-02-27 17:23:33 +01:00
|
|
|
trigger_parted|t
|
|
|
|
|
trigger_parted_p1|t
|
|
|
|
|
trigger_parted_p1_1|t
|
2021-07-16 23:29:22 +02:00
|
|
|
trigger_parted_p2|t
|
|
|
|
|
trigger_parted_p2_2|t
|
2013-10-26 17:24:04 +02:00
|
|
|
varchar_tbl|f
|
2019-02-17 18:37:31 +01:00
|
|
|
view_base_table|t
|
2013-10-26 17:24:04 +02:00
|
|
|
-- restore normal output mode
|
|
|
|
|
\a\t
|
2002-08-10 17:54:04 +02:00
|
|
|
--
|
|
|
|
|
-- another sanity check: every system catalog that has OIDs should have
|
|
|
|
|
-- a unique index on OID. This ensures that the OIDs will be unique,
|
|
|
|
|
-- even after the OID counter wraps around.
|
|
|
|
|
-- We exclude non-system tables from the check by looking at nspname.
|
|
|
|
|
--
|
|
|
|
|
SELECT relname, nspname
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = relnamespace JOIN pg_attribute a ON (attrelid = c.oid AND attname = 'oid')
|
|
|
|
|
WHERE relkind = 'r' and c.oid < 16384
|
|
|
|
|
AND ((nspname ~ '^pg_') IS NOT FALSE)
|
|
|
|
|
AND NOT EXISTS (SELECT 1 FROM pg_index i WHERE indrelid = c.oid
|
|
|
|
|
AND indkey[0] = a.attnum AND indnatts = 1
|
|
|
|
|
AND indisunique AND indimmediate);
|
2002-08-10 17:54:04 +02:00
|
|
|
relname | nspname
|
|
|
|
|
---------+---------
|
|
|
|
|
(0 rows)
|
|
|
|
|
|
2019-01-04 18:51:17 +01:00
|
|
|
-- check that relations without storage don't have relfilenode
|
|
|
|
|
SELECT relname, relkind
|
|
|
|
|
FROM pg_class
|
|
|
|
|
WHERE relkind IN ('v', 'c', 'f', 'p', 'I')
|
|
|
|
|
AND relfilenode <> 0;
|
|
|
|
|
relname | relkind
|
|
|
|
|
---------+---------
|
|
|
|
|
(0 rows)
|
|
|
|
|
|
