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.
v12.4 [Aug 15, 2020]
- Set a secure search_path in logical replication walsenders and apply workers: A malicious user of either the publisher or subscriber database could potentially cause execution of arbitrary SQL code by the role running replication, which is often a superuser. Some of the risks here are equivalent to those described in CVE-2018-1058, and are mitigated in this patch by ensuring that the replication sender and receiver execute with empty search_path settings. (As with CVE-2018-1058, that change might cause problems for under-qualified names used in replicated tables' DDL.) Other risks are inherent in replicating objects that belong to untrusted roles; the most we can do is document that there is a hazard to consider. (CVE-2020-14349)
- Make contrib modules' installation scripts more secure: Attacks similar to those described in CVE-2018-1058 could be carried out against an extension installation script, if the attacker can create objects in either the extension's target schema or the schema of some prerequisite extension. Since extensions often require superuser privilege to install, this can open a path to obtaining superuser privilege. To mitigate this risk, be more careful about the search_path used to run an installation script; disable check_function_bodies within the script; and fix catalog-adjustment queries used in some contrib modules to ensure they are secure. Also provide documentation to help third-party extension authors make their installation scripts secure. This is not a complete solution; extensions that depend on other extensions can still be at risk if installed carelessly. (CVE-2020-14350)
- Fix edge cases in partition pruning: When there are multiple partition key columns, generation of pruning tests could misbehave if some columns had no constraining WHERE clauses or multiple constraining clauses. This could lead to server crashes, incorrect query results, or assertion failures.
- Fix construction of parameterized BitmapAnd and BitmapOr index scans on the inside of partition-wise nestloop joins: A plan in which such a scan needed to use a value from the outside of the join would usually crash at execution.
- Fix incorrect plan execution when a partitioned table is subject to both static and run-time partition pruning in the same query, and a new partition is added concurrently with the query (Amit Langote, Tom Lane)
- In logical replication walsender, fix failure to send feedback messages after sending a keepalive message: This is a relatively minor problem when using built-in logical replication, because the built-in walreceiver will send a feedback reply (which clears the incorrect state) fairly frequently anyway. But with some other replication systems, such as pglogical, it causes significant performance issues.
- Fix firing of column-specific UPDATE triggers in logical replication subscribers: The code neglected to account for the possibility of column numbers being different between the publisher and subscriber tables, so that if those were indeed different, wrong decisions might be made about which triggers to fire.
- Update oldest xmin and LSN values during pg_replication_slot_advance(): This function previously failed to do that, possibly preventing resource cleanup (such as removal of no-longer-needed WAL segments) after manual advancement of a replication slot.
- Fix slow execution of ts_headline(): The phrase-search fix added in our previous set of minor releases could cause ts_headline() to take unreasonable amounts of time for long documents; to make matters worse, the query was not cancellable within the troublesome loop.
- Ensure the repeat() function can be interrupted by query cancel.
- Fix pg_current_logfile() to not include a carriage return (\r) in its result on Windows.
- Ensure that pg_read_file() and related functions read until EOF is reached: Previously, if not given a specific data length to read, these functions would stop at whatever file length was reported by stat(). That's unhelpful for pipes and other sorts of virtual files.
- Forbid numeric NaN values in jsonpath computations: Neither SQL nor JSON have the concept of NaN (not-a-number), but the jsonpath code attempted to allow such values anyway. This necessarily leads to nonstandard behavior, so it seems better to reject such values at the outset.
- Handle single Inf or NaN inputs correctly in floating-point aggregates: The affected aggregates are corr(), covar_pop(), regr_intercept(), regr_r2(), regr_slope(), regr_sxx(), regr_sxy(), regr_syy(), stddev_pop(), and var_pop(). The correct answer in such cases is NaN, but an algorithmic change introduced in PostgreSQL v12 had caused these aggregates to produce zero instead.
Feature-rich relational database known for its high performance and excellent concurrency
