On 14th of October Tome Lane committed new patch from Itagaki Tahahiro:
Log Message: ----------- Support SQL-compliant triggers ON COLUMNS, ie fire ONLY IF certain COLUMNS are named IN the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started TO USE a COLUMN that was there ALL along. catversion bumped anyway so that this commit IS included IN the history OF potentially interesting changes TO system catalog contents. Itagaki Takahiro
Pavel Stehule – hero for everybody writing stored procedures, wrote, and later Tom Lane committed patch which adds named arguments for functions:
Log Message: ----------- Support use of function argument names to identify which actual arguments match which function parameters. The syntax uses AS, for example funcname(value AS arg1, anothervalue AS arg2) Pavel Stehule
On 7th of October Alvaro Herrera committed his own patch, which adds quite interesting possibilty:
Log Message: ----------- Make it possibly TO specify GUC params per USER AND per DATABASE. CREATE a NEW catalog pg_db_role_setting WHERE they are now stored, AND better encapsulate the code that deals WITH settings INTO its realm. The OLD datconfig AND rolconfig COLUMNS are removed. psql has gained a \drds command TO display the settings. Backwards compatibility warning: while the backwards-compatible system views still have the config COLUMNS, they no longer completely represent the configuration FOR a USER OR DATABASE. Catalog version bumped.
Continue reading Waiting for 8.5 – GUC per user and database
One of the most common (or perhaps even the most common) question people have regarding PostgreSQL, is how to change privileges for all tables.
Usually they want something like MySQL's:
GRANT ... ON DATABASE.* TO ...
Which is interesting as it is actually 2 distinct features in one:
Now, thanks to 2 new patches – we have this possibility in PostgreSQL.
October, finally. “Only" 1 month of backlog in new features in 8.5, but I'm getting there 🙂
So, on 1st of October Tom Lane committed patch by Stef Walter:
Log Message: ----------- Support "samehost" and "samenet" specifications in pg_hba.conf, by enumerating the machine's IP interfaces to look for a match. Stef Walter
For some reason I cannot find it in mailing list archive, but luckily have copy of email (without all headers unfortunately).
Continue reading Waiting for 8.5 – ‘samehost' and ‘samenet' in pg_hba.conf
On 22nd of September, Tom Lane committed a patch by Petr Jelinek:
Log Message: ----------- Implement the DO statement TO support execution OF PL code WITHOUT HAVING TO CREATE a FUNCTION FOR it. PROCEDURAL languages now have an additional entry point, namely a FUNCTION TO EXECUTE an inline code block. This seemed a better design than trying TO hide the transient-ness OF the code FROM the PL. AS OF this patch, ONLY plpgsql has an inline handler, but probably people will soon WRITE handlers FOR the other standard PLs. IN passing, remove the long-dead LANCOMPILER OPTION OF CREATE LANGUAGE. Petr Jelinek
Andrew Gierth (RhodiumToad on irc) wrote, and Tom Lane committed:
Assorted improvements in contrib/hstore. Remove the 64K limit on the lengths of keys and values within an hstore. (This changes the on-disk format, but the old format can still be read.) Add support for btree/hash opclasses for hstore --- this is not so much for actual indexing purposes as to allow use of GROUP BY, DISTINCT, etc. Add various other new functions and operators. Andrew Gierth
On 29th of September (I know, there is a backlog – I'll work on it, I promise), Tom Lane committed another patch from Pavel Stehule:
Allow MOVE FORWARD n, MOVE BACKWARD n, MOVE FORWARD ALL, MOVE BACKWARD ALL in plpgsql. Clean up a couple of corner cases in the MOVE/FETCH syntax. Pavel Stehule
Continue reading Waiting for 8.5 – MOVE {FORWARD,BACKWARD} X
After very long discussions, on 10th of August, Tom Lane committed patch by Robert Haas:
Log Message: ----------- Extend EXPLAIN to support output in XML or JSON format. There are probably still some adjustments to be made in the details of the output, but this gets the basic structure in place. Robert Haas
On 3rd of August, Tatsuo Ishii committed patch by ITAGAKI Takahiro:
Log Message: ----------- Multi-threaded version of pgbench contributed by ITAGAKI Takahiro, reviewed by Greg Smith and Josh Williams. Following is the proposal from ITAGAKI Takahiro: Pgbench is a famous tool to measure postgres performance, but nowadays it does not work well because it cannot use multiple CPUs. On the other hand, postgres server can use CPUs very well, so the bottle-neck of workload is *in pgbench*. Multi-threading would be a solution. The attached patch adds -j (number of jobs) option to pgbench. If the value N is greater than 1, pgbench runs with N threads. Connections are equally-divided into them (ex. -c64 -j4 => 4 threads with 16 connections each). It can run on POSIX platforms with pthread and on Windows with win32 threads. Here are results of multi-threaded pgbench runs on Fedora 11 with intel core i7 (8 logical cores = 4 physical cores * HT). -j8 (8 threads) was the best and the tps is 4.5 times of -j1, that is a traditional result. $ pgbench -i -s10 $ pgbench -n -S -c64 -j1 => tps = 11600.158593 $ pgbench -n -S -c64 -j2 => tps = 17947.100954 $ pgbench -n -S -c64 -j4 => tps = 26571.124001 $ pgbench -n -S -c64 -j8 => tps = 52725.470403 $ pgbench -n -S -c64 -j16 => tps = 38976.675319 $ pgbench -n -S -c64 -j32 => tps = 28998.499601 $ pgbench -n -S -c64 -j64 => tps = 26701.877815 Is it acceptable to use pthread in contrib module? If ok, I will add the patch to the next commitfest.