Software-update: PostgreSQL 9.2

Versie 9.2 van PostgreSQL is vrijgegeven. Dit populaire 'opensource relational database management system' draait op een groot aantal besturingssystemen en is daardoor uitstekend inzetbaar in diverse omgevingen. Het is een afgeleide van Ingres, nadat de hoofdontwikkelaar daarvan voor zichzelf is begonnen en die database van opensource closedsource werd. Versie 9.2 bevat onder meer ingebakken ondersteuning voor JavaScript Object Notation en prestatieverbeteringen, en kan worden opgeschaald tot maar liefst 64 cores. Meer informatie over deze uitgave is in de release notes te vinden, dit zijn de belangrijkste verbeteringen:

Major enhancements include:

• Allow queries to retrieve data only from indexes, avoiding heap access (index-only scans)
• Allow the planner to generate custom plans for specific parameter values even when using prepared statements
• Improve the planner's ability to use nested loops with inner index scans
• Allow streaming replication slaves to forward data to other slaves (cascading replication)
• Allow pg_basebackup to make base backups from standby servers
• Add a pg_receivexlog tool to archive WAL file changes as they are written
• Add the SP-GiST (Space-Partitioned GiST) index access method
• Add support for range data types
• Add a JSON data type
• Add a security_barrier option for views
• Allow libpq connection strings to have the format of a URI
• Add a single-row processing mode to libpq for better handling of large result sets

Versienummer	9.2
Releasestatus	Final
Besturingssystemen	Windows 7, Windows 2000, Linux, BSD, Solaris, Windows Server 2003, Windows Vista, Windows Server 2008
Website	PostgreSQL
Download	http://www.postgresql.org/docs/9.2/static/release-9-2.html
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (11)

[s.stok]

En voor de mensen die met Ubuntu werken en toch de laatste versie willen hebben.
http://www.piware.de/2012...le-for-debian-and-ubuntu/

[MadEgg]

Best leuk, JSON syntax checking op database niveau, maar waar zou je dat voor nodig hebben? Je schrijft toch niet handmatig JSON welke je in de database zet, neem ik aan?

Ik sla zo nu en dan wel eens misc data op en in een JSON tekst-kolom, maar die wordt dan gegenereerd door de PHP json_encode functie, dus dan zou dit hoogstens bugs in een dergelijke functie kunnen blootleggen (of vice versa natuurlijk). Of krijgen we ook INI-syntax checking, XML-syntax checking en meer van dat soort reut?

[tympie]

Ik denk dat 't dezelfde kant opgaat als bijvoorbeeld met XML in Oracle. Eerste stap: zekerstellen dat de data echt valide JSON is. Volgende stap: rechstreeks queryen / relationeel benaderen van de inhoud.

[elmuerte]

XML is gewoon onderdeel van SQL:2003, niet iets bijzonders van Oracle, het zit bijvoorbeeld ook al jaren in PostgreSQL.

[Z-Dragon]

Een XML-type is er al.

[Verwijderd]

De database is de beste plaats om validatie van gegevens toe te passen (want centraal) in plaats van op diverse plekken in diverse applicaties (alhoewel dubbelop in dit geval geen probleem is). XML syntax checking zit er dik in (zie b.v. Oracle). INI files zie ik persoonlijk niet zo snel in een database terecht komen, misschien in een Git/Svn repo? Niet ongebruikelijk om daar de syntax te checken om indien fout een commit te rejecten

[Cyphax]

dus dan zou dit hoogstens bugs in een dergelijke functie kunnen blootleggen

Dat lijkt me een goed voorbeeld. Voor zo'n database geldt dat ie in principe niet weet waar de JSON vandaan komt. Jij gebruikt misschien JSON-parsers maar een ander niet. In elk geval wil je dat de database daar geen last van ondervindt.
Het is een mooie extra laag van zekerheid dat je database klopt.

[TheNephilim]

De toevoeging van JSON als datatype is wel bijzonder. Aan de andere kant slaan we natuurlijk data in allerlei formaten op en JSON is er ook zo één. Toch vind ik het een vreemde ontwikkeling.

[cariolive23]

Cascading replication, dat is nu iets waar ik blij van word! De load netjes spreiden over meerdere datacenters, zonder dat de master álle slaves van data moet voorzien.

Ben ook benieuwd naar de verbeterde performance, al speelt dat probleem minder omdat het nu al snel genoeg is.

[Nickvda]

Ben al vaak genoeg tegen applicaties aangelopen waar data opgeslagen wordt in een dikke longtext- waar uiteindelijk JSON objecten in worden geschreven.

Snap het gemekker niet zo.

[Huismus]

Ik denk dat het ook compressie is.
Als je weet dat de data JSON-encoded is, dan kun je het veel beter/efficienter opslaan, en (mogelijk) sneller opvragen.