5 Commits (ecacbdbcee67e202cfcaa1180da170b9f13654bb)

Author	SHA1	Message	Date
Andrew Dunstan	d9134d0a35	Introduce jsonb, a structured format for storing json. ... The new format accepts exactly the same data as the json type. However, it is stored in a format that does not require reparsing the orgiginal text in order to process it, making it much more suitable for indexing and other operations. Insignificant whitespace is discarded, and the order of object keys is not preserved. Neither are duplicate object keys kept - the later value for a given key is the only one stored. The new type has all the functions and operators that the json type has, with the exception of the json generation functions (to_json, json_agg etc.) and with identical semantics. In addition, there are operator classes for hash and btree indexing, and two classes for GIN indexing, that have no equivalent in the json type. This feature grew out of previous work by Oleg Bartunov and Teodor Sigaev, which was intended to provide similar facilities to a nested hstore type, but which in the end proved to have some significant compatibility issues. Authors: Oleg Bartunov, Teodor Sigaev, Peter Geoghegan and Andrew Dunstan. Review: Andres Freund	12 years ago
Andrew Dunstan	a18167510f	Use a new hstore extension version for added json functions. ... This should have been done when the json functionality was added to hstore in 9.3.0. To handle this correctly, the upgrade script therefore uses conditional logic by using plpgsql in a DO statement to add the two new functions and the new cast. If hstore_to_json_loose is detected as already present and dependent on the hstore extension nothing is done. This will require that the database be loaded with plpgsql. People who have installed the earlier and spurious 1.1 version of hstore will need to do: ALTER EXTENSION hstore UPDATE; to pick up the new functions properly.	12 years ago
Robert Haas	b60653bc0b	Remove hstore's text => text operator. ... Since PostgreSQL 9.0, we've emitted a warning message when an operator named => is created, because the SQL standard now reserves that token for another use. But we've also shipped such an operator with hstore. Use of the function hstore(text, text) has been recommended in preference to =>(text, text). Per discussion, it's now time to take the next step and stop shipping the operator. This will allow us to prohibit the use of => as an operator name in a future release if and when we wish to support the SQL standard use of this token. The release notes should mention this incompatibility. Patch by me, reviewed by David Wheeler, Dimitri Fontaine and Tom Lane.	14 years ago
Tom Lane	f5fc1de501	Bring hstore's comment into line with style of other contrib comments. ... All the other ones that are primarily a new datatype say "data type for <purpose>", so make this one similar.	15 years ago
Tom Lane	629b3af27d	Convert contrib modules to use the extension facility. ... This isn't fully tested as yet, in particular I'm not sure that the "foo--unpackaged--1.0.sql" scripts are OK. But it's time to get some buildfarm cycles on it. sepgsql is not converted to an extension, mainly because it seems to require a very nonstandard installation process. Dimitri Fontaine and Tom Lane	15 years ago