The most important, what happened during the last year, the transition from CVS to GIT. Of course,

After a year there's a new version of PostgreSQL - or we have a beta - and it is therefore unclear what will and will not 9.1. Basically, up to a MERGE command, which will be until 9.2 were plans for this version met. PostgreSQL now supports COLLATION according to ANSI / SQL. There is also support for SQL / MED (external reading csv files).
Overall, the changes are not as many as in 9.0, but there is still enough of them - constantly adding new features. During the year, was accepted by several hundred patches ups tracker (source PostgreSQL exceeded the magic threshold of one million lines). ups tracker Users PostGIS welcome major expansion GiST indexes KNNGIST and yet unprecedented progress in the development of PL / Python. For enterprise solutions has meaning new implementation SERIALIZABLE transaction isolation levels. For temporary ups tracker storage are so interesting unlogged tables.
The most important, what happened during the last year, the transition from CVS to GIT. Of course, users could not care less that the system for managing source code used by the project. However, the way to keep the source ups tracker code is essential for developers community. GIT selection was preceded by several years of discussions. I own conversion was not so completely simple and painless. PostgreSQL developers certainly did not want to lose the history stored in the CVS repository and CVS infrastructure links, which proved to be a problem during the pilot project. A few months developers of PostgreSQL core team participated in the development of GIT - for up to one half conversion from CVS. SQL
A tiny but crucial change is the transition to the so-called ANSI SQL strings. Starting with PostgreSQL 9.1 implicitly supported escape sequences in strings (ed. In the configuration can be enabled). If needed escape sequence must be used so-called extended chain (extended strings): postgres = # SELECT e'aa \ taa '; ? Column? ------------ Aa aa (1 row)
Rating 9.1 is not easy. Most of the news (except perhaps KNNGIST) I did not label as revolutionary or groundbreaking. Some new features are replacing the previous system improvisation. Others do not currently significant "added value", but the door open for future ups tracker use (eg. Infrastructure proSQL / MED). If I wanted to shock, so I put in the first place support ups tracker functional ups tracker dependencies in the GROUP BY clause. Old adage that attribute must be located in either an aggregate ups tracker function or the GROUP BY clause is no longer applicable: - column id must be the primary key of the Employees ups tracker table postgres = # SELECT * FROM employees; id | Name | Surname ---- + ------- + ---------- 1 | Paul | Stěhule 2 | Tomas | Marne (2 rows) postgres = # SELECT * FROM wages; zamestnanec_id | paid | Amount ---------------- + ------------ + ---------- 1 | 2010-06 -01 | 10000.00 1 | 2010-07-01 | 10020.00 2 | 2010-05-01 | 8020.00 ups tracker 2 | 2010-06-01 | 12020.00 2 | 2010-07-01 | 13020.00 (5 rows) - query written using functional dependence postgres = # SELECT name, surname, sum (amount) FROM Employees JOIN wages ON id = zamestnanec_id GROUP BY id; Name | Last names | + ------- sum ---------- + ---------- Pavel | Stěhule | 20020.00 Tomas | Marne | 33060.00 (2 rows)
So far, the only supported functional dependency is a dependency on the primary key. After this function long called MySQL users. I'm not sure if they will be satisfied. ups tracker PostgreSQL still does not allow to write a query with an aggregate function freely.
PostgreSQL support so COLLATION catching ups tracker other databases to support multi language applications. Now you can define the locale for the column level. Data in a specific column can be sorted once by Czech rules, and again under different rules. Small issue is a platform dependency identifier COLLATE (Microsoft uses a different system than Unix locales). Fortunately, you can create custom ups tracker COLLATE and the difference in names between different platforms bridge. postgres = # CREATE COLLATION czech FROM "cs_CZ.utf8"; CREATE COLLATION postgres = # CREATE TABLE people (name VARCHAR COLLATE English); CREATE ups tracker TABLE postgres = # \ d people Table "public.lide" Column | Type | Modifiers ---------- + ------------------- + --------------- surname | Character Varying | collate czech postgres = # show LC_COLLATE; LC_COLLATE ------------ en_US.utf8 ups tracker (1 row) postgres = # SELECT * FROM people ORDER BY 1; surname ----------- Crha Bare Hynek Chromečka (4 rows) postgres = # SELECT * FROM people ORDER BY lastname COLLATE ups tracker "en_US.utf8"; surname ups tracker ----------- Chromečka Crha Bare Hynek (4 rows)
The only restriction is that all the data in the database must have the same coding - that you can not have one column with coding latin2 others with latin1 and third with UTF8. For this reason, it is recommended to prefer UTF8 (NB .: favorite collate C is applicable only for 8bit encoding. Its period is ucs_basic for UTF8 collation).
Users waiting for the opportunity ups tracker to use INSERT, UPDATE, DELETE queries in CTE. The opportunity is here now - concatenation SQL statements (DML statements ups tracker pipelining) postgres = # SELECT * FROM foo; and ---- 30 20 10 (3 rows) postgres = # SELECT * FROM deleted; and --- (0 rows) postgres = # t1 AS WITH (DELETE RETURNING FROM foo *) AS t2