Runs stored procedures in more than a dozen programming languages, including Java, etc. Permits the database designer to create rules which identify specific operations for a given table or view. Offers the ability to database designers to derive new tables from other tables.
PostgreSQL is an object-relational database management system (ORDBMS) created originally at University of California. Its SQL implementation strongly conforms to the ANSI-SQL 92/99 standards supporting it. It has full support for triggers, views, queries, stored procedures, joins, multiple languages, among others. Some features of this Database include multi version concurrency control (MVCC), point in time recovery, tablespaces, replication (asynchronous), nested transaction, online backups, fault tolerance and many other sophisticated features to provide data integrity.
Some of the allowed maximum values offer big possibilities for huge database systems: unlimited maximum Database size, rows per table and indexes per table, or 32TB maximum for a table's size. The system supports SSL and IPv6 protocols. It also supports many data types, like arrays and XML among many others. Third party contributions are also important for this ORDBMS, because many of the tools to develop, access or use this database exist only because of them. The system also supports GIS (Geographical Information System) data and it can be used for mapping and localization purposes.
The current release includes many fixes reported by its contributors and some new features like full text search integration, support for SQL/XML standard, includes some new data types (enumerated, arrays of composite types, XML, Universal Unique Identifier), it improves logging and statics collections, and much more.
Its installation process is very easy to perform; moreover, some third party utilities and programs are included depending your requests or needs. The Stack Builder utility manages all the installations. Its GUI depends on how would you like to view your data; a nice program to view and manage your databases is pgAdmin III. Its documentation is very complete and detailed; you can find a lot of documentation in its website and included with the program. PostgreSQL works in Linux, UNIX and Windows platforms.
v13.2
Changes:
- Fix failure to check per-column SELECT privileges in some join queries (Tom Lane).
In some cases involving joins, the parser failed to record all the columns read by a query in the column-usage bitmaps that are used for permissions checking. Although the executor would still insist on some sort of SELECT privilege to run the query, this meant that a user having SELECT privilege on only one column of a table could nonetheless read all its columns through a suitably crafted query.
A stored view that is subject to this problem will have incomplete column-usage bitmaps, and thus permissions will still not be enforced properly on the view after updating. In installations that depend on column-level permissions for security, it is recommended to CREATE OR REPLACE all user-defined views to cause them to be re-parsed.
The PostgreSQL Project thanks Sven Klemm for reporting this problem. (CVE-2021-20229).
- Fix information leakage in constraint-violation error messages (Heikki Linnakangas).
If an UPDATE command attempts to move a row to a different partition but finds that it violates some constraint on the new partition, and the columns in that partition are in different physical positions than in the parent table, the error message could reveal the contents of columns that the user does not have SELECT privilege on. (CVE-2021-3393).
- Fix incorrect detection of concurrent page splits while inserting into a GiST index (Heikki Linnakangas).
Concurrent insertions could lead to a corrupt index with entries placed in the wrong pages. It's recommended to reindex any GiST index that's been subject to concurrent insertions.
- Fix CREATE INDEX CONCURRENTLY to wait for concurrent prepared transactions (Andrey Borodin).
At the point where CREATE INDEX CONCURRENTLY waits for all concurrent transactions to complete so that it can see rows they inserted, it must also wait for all prepared transactions to complete, for the same reason. Its failure to do so meant that rows inserted by prepared transactions might be omitted from the new index, causing queries relying on the index to miss such rows. In installations that have enabled prepared transactions (max_prepared_transactions > 0), it's recommended to reindex any concurrently-built indexes in case this problem occurred when they were built.
- Avoid crash when trying to rescan an aggregation plan node that has both hashed and sorted grouping sets (Jeff Davis).
- Fix possible incorrect query results when a hash aggregation node spills some tuples to disk (Tom Lane).
It was possible for aggregation grouping values to be replaced by nulls when the tuples are read back in, leading to wrong answers.
- Fix edge case in incremental sort (Neil Chen).
If the last tuple of a sort batch chanced to be the first tuple of the next group of already-sorted tuples, the code did the wrong thing. This could lead to “retrieved too many tuples in a bounded sort” error messages, or to silently-wrong sorting results.
- Avoid crash when a CALL or DO statement that performs a transaction rollback is executed via extended query protocol (Thomas Munro, Tom Lane).
In PostgreSQL 13, this case reliably caused a null-pointer dereference. In earlier versions the bug seems to have no visible symptoms, but it's not quite clear that it could never cause a problem.
- Avoid unnecessary errors with BEFORE UPDATE triggers on partitioned tables (Álvaro Herrera).
A BEFORE UPDATE FOR EACH ROW trigger that modified the row in any way prevented UPDATE from moving the row to another partition when needed; but there is no longer any reason for this restriction.
- Fix partition pruning logic to handle asymmetric hash partition sets (Tom Lane).
If a hash-partitioned table has unequally-sized partitions (that is, varying modulus values), or it lacks partitions for some remainder values, then the planner's pruning logic could mistakenly conclude that some partitions don't need to be scanned, leading to failure to find rows that the query should find.
- Avoid incorrect results when WHERE CURRENT OF is applied to a cursor whose plan contains a MergeAppend node (Tom Lane).
This case is unsupported (in general, a cursor using ORDER BY is not guaranteed to be simply updatable); but the code previously did not reject it, and could silently give false matches.
- Fix crash when WHERE CURRENT OF is applied to a cursor whose plan contains a custom scan node (David Geier).
- Fix planner's mishandling of placeholders whose evaluation should be delayed by an outer join (Tom Lane).
Feature-rich relational database known for its high performance and excellent concurrency
