nested hstore patch
Hi!
Attatched patch adds nesting feature, types (string, boll and numeric values),
arrays and scalar to hstore type.
All new features are described in PGConf.EU talk
http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2013.pdf (since PGCon
some features was added).
Patch includes:
1 implementaion SRF_RETURN_NEXT_NULL()
2 contrib/hstore changes
3 docs of new hstore module (many thanks to David E. Wheeler
<david.wheeler@pgexperts.com>)
In current state patch is in WIP status, for short period I plan to move support
of binary nested structure to core to share binary representation for hstore and
json types.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
Attachments:
On 11/12/2013 01:35 PM, Teodor Sigaev wrote:
Hi!
Attatched patch adds nesting feature, types (string, boll and numeric
values), arrays and scalar to hstore type.All new features are described in PGConf.EU talk
http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2013.pdf
(since PGCon some features was added).Patch includes:
1 implementaion SRF_RETURN_NEXT_NULL()
2 contrib/hstore changes
3 docs of new hstore module (many thanks to David E. Wheeler
<david.wheeler@pgexperts.com>)In current state patch is in WIP status, for short period I plan to
move support of binary nested structure to core to share binary
representation for hstore and json types.
Thanks, Teodor.
As soon as we have that shared binary representation available, I will
be working on adapting it to JSON.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/12/13, 1:35 PM, Teodor Sigaev wrote:
Attatched patch adds nesting feature, types (string, boll and numeric
values), arrays and scalar to hstore type.
Could you check your email client for next time? It's sending
Content-Type: application/x-tar for a *.patch.gz file.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/13/2013 01:37 AM, Andrew Dunstan wrote:
On 11/12/2013 01:35 PM, Teodor Sigaev wrote:
Hi!
Attatched patch adds nesting feature, types (string, boll and numeric
values), arrays and scalar to hstore type.All new features are described in PGConf.EU talk
http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2013.pdf
(since PGCon some features was added).Patch includes:
1 implementaion SRF_RETURN_NEXT_NULL()
2 contrib/hstore changes
3 docs of new hstore module (many thanks to David E. Wheeler
<david.wheeler@pgexperts.com>)In current state patch is in WIP status, for short period I plan to
move support of binary nested structure to core to share binary
representation for hstore and json types.Thanks, Teodor.
As soon as we have that shared binary representation available, I will
be working on adapting it to JSON.
As I remember from earlier discussions, current json has some
artefacts that some people want to preserve and which are incompatible
with hstore approach where you have actual object behind the serialisation.
I remember strong voices in support of *not* normalising json, so that
things like
{"a":1,"a":true, "a":"b", "a":none}
would go through the system unaltered, for claimed standard usage of
json as
"processing instructions". That is as source code which can possibly
converted
to JavaScript Object and not something that would come out of
serialising of
any existing JavaScript Object.
I suggest we add another type, maybe jsobj, which has input and output
as standard
"JSON" but which is defined from the start to be equivalent of existing
object
and not "preservable source code" to such object.
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Nov 13, 2013, at 3:59 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
I remember strong voices in support of *not* normalising json, so that
things like{"a":1,"a":true, "a":"b", "a":none}
would go through the system unaltered, for claimed standard usage of
json as
"processing instructions". That is as source code which can possibly
converted
to JavaScript Object and not something that would come out of
serialising of
any existing JavaScript Object.
My recollection from PGCon was that there was consensus to normalize on the way in -- or at least, if we switched to a binary representation as proposed by Oleg & Teodor, it was not worth the hassle to try to keep it.
I suggest we add another type, maybe jsobj, which has input and output
as standard
"JSON" but which is defined from the start to be equivalent of existing
object
and not "preservable source code" to such object.
-1 Let's try to keep this simple. See also VARCHAR and VARCHAR2 on Oracle.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/14/2013 01:32 AM, David E. Wheeler wrote:
On Nov 13, 2013, at 3:59 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
I remember strong voices in support of *not* normalising json, so that
things like{"a":1,"a":true, "a":"b", "a":none}
would go through the system unaltered, for claimed standard usage of
json as
"processing instructions". That is as source code which can possibly
converted
to JavaScript Object and not something that would come out of
serialising of
any existing JavaScript Object.My recollection from PGCon was that there was consensus to normalize on
the way in --
Great news! I remember advocating this approach in the mailing lists
but having been out-voted based on "current real-world usage out there" :)
or at least, if we switched to a binary representation as proposed by
Oleg & Teodor, it was not worth the hassle to try to keep it.
Very much agree. For the source code approach I'd recommend
text type with maybe a check that it is possible to convert it to json.
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic O�
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/14/2013 03:21 AM, Hannu Krosing wrote:
On 11/14/2013 01:32 AM, David E. Wheeler wrote:
On Nov 13, 2013, at 3:59 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
I remember strong voices in support of *not* normalising json, so that
things like{"a":1,"a":true, "a":"b", "a":none}
would go through the system unaltered, for claimed standard usage of
json as
"processing instructions". That is as source code which can possibly
converted
to JavaScript Object and not something that would come out of
serialising of
any existing JavaScript Object.My recollection from PGCon was that there was consensus to normalize on
the way in --Great news! I remember advocating this approach in the mailing lists
but having been out-voted based on "current real-world usage out there" :)or at least, if we switched to a binary representation as proposed by
Oleg & Teodor, it was not worth the hassle to try to keep it.Very much agree. For the source code approach I'd recommend
text type with maybe a check that it is possible to convert it to json.
I don't think you and David are saying the same thing. AIUI he wants one
JSON type and is prepared to discard text preservation (duplicate keys
and key order). You want two json types, one of which would feature text
preservation.
Correct me if I'm wrong.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/14/2013 01:47 PM, Andrew Dunstan wrote:
On 11/14/2013 03:21 AM, Hannu Krosing wrote:
On 11/14/2013 01:32 AM, David E. Wheeler wrote:
On Nov 13, 2013, at 3:59 PM, Hannu Krosing <hannu@2ndquadrant.com>
wrote:I remember strong voices in support of *not* normalising json, so that
things like{"a":1,"a":true, "a":"b", "a":none}
would go through the system unaltered, for claimed standard usage of
json as
"processing instructions". That is as source code which can possibly
converted
to JavaScript Object and not something that would come out of
serialising of
any existing JavaScript Object.My recollection from PGCon was that there was consensus to normalize on
the way in --Great news! I remember advocating this approach in the mailing lists
but having been out-voted based on "current real-world usage out
there" :)or at least, if we switched to a binary representation as proposed by
Oleg & Teodor, it was not worth the hassle to try to keep it.Very much agree. For the source code approach I'd recommend
text type with maybe a check that it is possible to convert it to json.I don't think you and David are saying the same thing. AIUI he wants
one JSON
type and is prepared to discard text preservation (duplicate keys and
key order).
You want two json types, one of which would feature text preservation.
I actually *want* the same thing that David wants, but I think that
Merlin has
valid concerns about backwards compatibility.
If we have let this behaviour in, it is not nice to break several uses
of it now.
If we could somehow turn "old json" into a text domain with json syntax
check
(which it really is up to 9.3) via pg_upgrade that would be great.
It would be the required for pg_dump to have some swicth to output
different typename in CREATE TABLE and similar.
Correct me if I'm wrong.
cheers
andrew
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic O�
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2013-11-12 22:35:31 +0400, Teodor Sigaev wrote:
Attatched patch adds nesting feature, types (string, boll and numeric
values), arrays and scalar to hstore type.
I took a quick peek at this:
* You cannot simply catch and ignore errors by doing
+ PG_TRY();
+ {
+ n = DatumGetNumeric(DirectFunctionCall3(numeric_in, CStringGetDatum(s->val), 0, -1));
+ }
+ PG_CATCH();
+ {
+ n = NULL;
+ }
+ PG_END_TRY();
That skips cleanup and might ignore some errors (think memory allocation
failures). But why do you even want to silently ignore errors there?
* Shouldn't the checks for v->size be done before filling the
datastructures in makeHStoreValueArray() and makeHStoreValuePairs()?
* could you make ORDER_PAIRS() a function instead of a macro? It's
pretty long and there's no reason not to use a function.
* You call numeric_recv via recvHStoreValue via recvHStore without
checks on the input length. That seems - without having checked it in
detail - a good way to read unrelated memory. Generally ISTM the input
needs to be more carefully checked in the whole recv function.
* There's quite some new new, completely uncommented, code. Especially
in hstore_op.c.
* the _PG_init you added should probably do a EmitWarningsOnPlaceholders().
* why does hstore need it's own atoi?
* shouldn't all the function prototypes be marked as externs?
* Lots of trailing whitespaces, quite some long lines, cuddly braces,
...
* I think hstore_compat.c's header should be updated.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Nov 14, 2013 at 05:50:02PM +0100, Hannu Krosing wrote:
If we could somehow turn "old json" into a text domain with json syntax
check
(which it really is up to 9.3) via pg_upgrade that would be great.It would be the required for pg_dump to have some swicth to output
different typename in CREATE TABLE and similar.
I don't think pg_upgrade isn't in a position to handle this. I think it
would require a script to be run after pg_upgrade completes.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Nov 13, 2013 at 6:59 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
I remember strong voices in support of *not* normalising json, so that
things like{"a":1,"a":true, "a":"b", "a":none}
would go through the system unaltered, for claimed standard usage of
json as
"processing instructions". That is as source code which can possibly
converted
to JavaScript Object and not something that would come out of
serialising of
any existing JavaScript Object.
Yeah, as the guy who wrote the original version of the JSON type,
which works just exactly like the XML type does, I stronly object to
changing the behavior. And doubly so now that it's released, as we
would be breaking backward compatibility.
I suggest we add another type, maybe jsobj, which has input and output
as standard
"JSON" but which is defined from the start to be equivalent of existing
object
and not "preservable source code" to such object.
I think this was the consensus solution when this was last discussed,
and I support it. There is similar space for a binary XML data type
if someone feels like implementing it. I think the names that were
proposed previously were something like jsonb and xmlb.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Nov 19, 2013 at 10:51:06AM -0500, Robert Haas wrote:
I think this was the consensus solution when this was last discussed,
and I support it. There is similar space for a binary XML data type
if someone feels like implementing it. I think the names that were
proposed previously were something like jsonb and xmlb.
The natural name is OBJSON, meaning object JSON, because as PostgreSQL
people, we have to double-use letters wherever possible. ;-)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/19/2013 10:51 AM, Robert Haas wrote:
I suggest we add another type, maybe jsobj, which has input and output
as standard
"JSON" but which is defined from the start to be equivalent of existing
object
and not "preservable source code" to such object.I think this was the consensus solution when this was last discussed,
and I support it. There is similar space for a binary XML data type
if someone feels like implementing it. I think the names that were
proposed previously were something like jsonb and xmlb.
I think that's the consensus position on a strategy.
JSONB seems to be the current winner min the name stakes.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Nov 19, 2013 at 10:55 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Nov 19, 2013 at 10:51:06AM -0500, Robert Haas wrote:
I think this was the consensus solution when this was last discussed,
and I support it. There is similar space for a binary XML data type
if someone feels like implementing it. I think the names that were
proposed previously were something like jsonb and xmlb.The natural name is OBJSON, meaning object JSON, because as PostgreSQL
people, we have to double-use letters wherever possible. ;-)
Personally, I think the patch author should just run ps auxww | md5 |
sed 's/^[^0-9]//' | cut -c1-8 and call the new data type by the
resulting name.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/19/2013 11:00 AM, Robert Haas wrote:
On Tue, Nov 19, 2013 at 10:55 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Nov 19, 2013 at 10:51:06AM -0500, Robert Haas wrote:
I think this was the consensus solution when this was last discussed,
and I support it. There is similar space for a binary XML data type
if someone feels like implementing it. I think the names that were
proposed previously were something like jsonb and xmlb.The natural name is OBJSON, meaning object JSON, because as PostgreSQL
people, we have to double-use letters wherever possible. ;-)Personally, I think the patch author should just run ps auxww | md5 |
sed 's/^[^0-9]//' | cut -c1-8 and call the new data type by the
resulting name.
My personal vote goes for "marmaduke". I've been dying to call some
builtin object that for ages.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/12/13, 1:35 PM, Teodor Sigaev wrote:
Hi!
Attatched patch adds nesting feature, types (string, boll and numeric
values), arrays and scalar to hstore type.
Documentation doesn't build:
openjade:hstore.sgml:206:16:E: document type does not allow element "VARLISTENTRY" here; assuming missing "VARIABLELIST" start-tag
Compiler warnings:
hstore_io.c: In function 'array_to_hstore':
hstore_io.c:1736:29: error: 'result' may be used uninitialized in this function [-Werror=maybe-uninitialized]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Nov 20, 2013, at 6:19 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
openjade:hstore.sgml:206:16:E: document type does not allow element "VARLISTENTRY" here; assuming missing "VARIABLELIST" start-tag
Thanks, I fixed this one.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Nov 12, 2013, at 10:35 AM, Teodor Sigaev <teodor@sigaev.ru> wrote:
Hi!
Attatched patch adds nesting feature, types (string, boll and numeric values), arrays and scalar to hstore type.
My apologies for not getting to this sooner, work has been a bit nutty. The truth is that I reviewed this patch quite a bit a month back, mostly so I could write documentation, the results of which are included in this patch. And I'm super excited for what's to come in the next iteration, as I hear that Teodor and Andrew are hard at work adding jsonb as a binary-compatible JSON data type.
Meanwhile, for this version, a quick overview of what has changed since 9.2.
Contents & Purpose
==================
Improved Data Type Support
--------------------------
* Added data type support for values. Previously they could only be strings or NULL, but with this patch they can also be numbers or booleans.
* Added array support. Values can be arrays of other values. The format for arrays is a bracketed, comma-delimited list.
* Added nesting support. hstore values can themselves be hstores. Nested hstores are wrapped in braces, but the root-level hstore is not (for compatibility with the format of previous versions of hstore).
* An hstore value is no longer required to be an hstore object. It can now be any scalar value.
These three items make the basic format feature-complete with JSON. Here's an example where the values are scalars:
=% SELECT 'foo'::hstore, '"hi \"bob\""'::hstore, '1.0'::hstore, 'true'::hstore, NULL::hstore;
hstore | hstore | hstore | hstore | hstore
--------+--------------+--------+--------+--------
"foo" | "hi \"bob\"" | 1.0 | t |
And here are a couple of arrays with strings, numbers, booleans, and NULLs:
SELECT '[k,v]'::hstore, '[1.0, "hi there", false, null]'::hstore;
hstore | hstore
------------+----------------------------
["k", "v"] | [1.0, "hi there", f, NULL]
Here's a complicated example formatted with `hstore.pretty_print` enabled.
=% SET hstore.pretty_print=true;
=% SELECT '{
"type" => "Feature",
"bbox" => [-180.0, -90.0, 180.0, 90.0],
"geometry" => {
"type" => "Polygon",
"coordinates" => [[
[-180.0, 10.0], [20.0, 90.0], [180.0, -5.0], [-30.0, -90.0]
]]
}
}'::hstore;
hstore
--------------------------
"bbox"=> +
[ +
-180.0, +
-90.0, +
180.0, +
90.0 +
], +
"type"=>"Feature", +
"geometry"=> +
{ +
"type"=>"Polygon", +
"coordinates"=> +
[ +
[ +
[ +
-180.0, +
10.0 +
], +
[ +
20.0, +
90.0 +
], +
[ +
180.0, +
-5.0 +
], +
[ +
-30.0, +
-90.0 +
] +
] +
] +
}
So, exact feature parity with the JSON data type.
* hstore.pretty_print is a new GUC, specifically to allow an HSTORE value to be pretty-printed. There is also a function to pretty-print, so we might be able to just do away with the GUC.
Interface
---------
* New operators:
+ `hstore -> int`: Get string value at array index (starting at 0)
+ `hstore ^> text`: Get numeric value for key
+ `hstore ^> int`: Get numeric value at array index
+ `hstore ?> text`: Get boolean value for key
+ `hstore ?> int`: Get boolean value at array index
+ `hstore #> text[]`: Get string value for key path
+ `hstore #^> text[]`: Get numeric value for key path
+ `hstore #?> text[]`: Get boolean value for key path
+ `hstore %> text`: Get hstore value for key
+ `hstore %> int`: Get hstore value at array index
+ `hstore #%> text[]`: Get hstore value for key path
+ `hstore ? int`: Does hstore contain array index
+ `hstore #? text[]`: Does hstore contain key path
+ `hstore - int`: Delete index from left operand
+ `hstore #- text[]`: Delete key path from left operand
* New functions:
+ `hstore(text)`: Make a text scalar hstore
+ `hstore(numeric)`: Make a numeric scalar hstore
+ `hstore(boolean)`: Make a boolean scalar hstore
+ `hstore(text, hstore)`: Make a nested hstore
+ `hstore(text, numeric)`: Make an hstore with a key and numeric value
+ `hstore(text, boolean)`: Make an hstore with a key and boolean value
+ `array_to_hstore(anyarray): Make an array hstore from an SQL array
+ `hvals(hstore)` Get values as a set of hstore values
+ `json_to_hstore(json)` Convert JSON to hstore
+ `each_hstore(hstore)` Get set of hstore key/value pairs
+ `hstore_typeof(hstore)` Return text name for the hstore type (hash, array, text, numeric, etc.)
+ `replace(hstore,text[],hstore)`: Replace value at specified path
+ `concat_path(hstore,text[],hstore)`: Concatenate hstore value at specified path
+ `hstore_print(hstore, params)`: Format hstore as text
The hstore_print() function has a number of optional boolean parameters to affect how the resulting text is formatted. They all default to false:
- pretty_print
- array_curly_braces: use {} instead of [] for arrays
- root_hash_decorated: Use {} for the root hash
- json: Format as JSON
- loose: Try to parse numbers and booleans from text values
Other Changes
-------------
* New casts: JSON and HSTORE can be cast to each other. I don't think they're implicit, though the forthcoming jsonb data type might support explicit casting to and from hstore, since internally they will be identical.
* The internal representation has been changed, but should be backward (and pg_upgrade) compatible, just as Andrew Gierth's change from 8.4 to 9.0 was. One can do an in-place update to rewrite all records at once. Of course, nested and/or non-hash hstore values dumped from 9.4 will not be able to be loaded into 9.3.
* GIN indexing is now supported. This is actually pretty amazing. For an hstore value, even hash keys are considered values, as far as the index is concerned. This makes it efficient to find hstore values that contain a key. I wrote an example in this blog post:
http://theory.so/pg/2013/10/25/indexing-nested-hstore/
Submission review
=================
* Is the patch in a patch format which has context? Yes.
* Does it apply cleanly to the current git master? It did for me, though I think Peter has found an issue or two since.
* Does it include reasonable tests, necessary doc patches, etc? Yes.
Usability review
================
* Does the patch actually implement what it says it does? Yes.
* Do we want that? OH yes.
* Do we already have it? No.
* Does it follow SQL spec, or the community-agreed behavior? Yes, though want jsonb, too.
* Does it include pg_dump support? Yes
* Are there dangers? Could break backward compatibility, though I don't think it does.
* Have all the bases been covered? I think so
Feature test
============
* Does the feature work as advertised? Yes.
* Are there corner cases the author has failed to consider? All I noticed were promptly fixed.
* Are there any assertion failures or crashes? No
Performance review
==================
* Does the patch slow down simple tests? No
* If it claims to improve performance, does it? Yes, with GIN index support. Loading hstore values is slower than loading JSON, but everything else is faster than JSON.
* Does it slow down other things? No.
Coding review
=============
* Does it follow the project guidelines? Yes.
* Are there portability issues? Unknown
* Will it work on Windows/BSD etc? Tested on OS X only.
* Are the comments sufficient and accurate? Yes.
* Does it do what it says, correctly? As best I can tell, yes.
* Does it produce compiler warnings? No.
* Can you make it crash? No, but I did find a bug or two that was promptly fixed.
Architecture review
===================
* Is everything done in a way that fits together coherently with other features/modules? yes.
* Are there interdependencies that can cause problems? No
Conclusion
==========
I love where nested hstore is going, especially since it will be used for jsonb, too. The nesting, data type, and GIN index support is really great, and the new constructors provide a nice SQL API that make it easy to use. I think that the next version of this patch will be full of win for the project.
This was considered a WIP patch, since the jsonb support is still forthcoming, so it's appropriate to leave it marked “Returned with feedback”. As Andrew is doing much of that work, the code itself will get a much closer examination from him. But for the hstore feature itself, I think the current interface and features are ready to go.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WMad7974f5bbbd0cf694014bd0c5e1d1bd077531bb0a699f6a724d21fbb01d3103c39d359cf343405d52d99256b39a3070@asav-2.01.com
On 2013-12-20 15:16:30 -0800, David E. Wheeler wrote:
But for the hstore feature itself, I think the current interface and features are ready to go.
I think this patch needs significant amount of work because it can be
considered ready for committer. I found the list of issues in
http://archives.postgresql.org/message-id/20131118163633.GE20305%40awork2.anarazel.de
within 10 minutes, indicating that it clearly cannot be ready yet.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler <david@justatheory.com> wrote:
* New operators: + `hstore -> int`: Get string value at array index (starting at 0) + `hstore ^> text`: Get numeric value for key + `hstore ^> int`: Get numeric value at array index + `hstore ?> text`: Get boolean value for key + `hstore ?> int`: Get boolean value at array index + `hstore #> text[]`: Get string value for key path + `hstore #^> text[]`: Get numeric value for key path + `hstore #?> text[]`: Get boolean value for key path + `hstore %> text`: Get hstore value for key + `hstore %> int`: Get hstore value at array index + `hstore #%> text[]`: Get hstore value for key path + `hstore ? int`: Does hstore contain array index + `hstore #? text[]`: Does hstore contain key path + `hstore - int`: Delete index from left operand + `hstore #- text[]`: Delete key path from left operand
Although in some ways there's a certain elegance to this, it also
sorta looks like punctuation soup. I can't help wondering whether
we'd be better off sticking to function names.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/23/2013 12:28 PM, Robert Haas wrote:
On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler <david@justatheory.com> wrote:
* New operators: + `hstore -> int`: Get string value at array index (starting at 0) + `hstore ^> text`: Get numeric value for key + `hstore ^> int`: Get numeric value at array index + `hstore ?> text`: Get boolean value for key + `hstore ?> int`: Get boolean value at array index + `hstore #> text[]`: Get string value for key path + `hstore #^> text[]`: Get numeric value for key path + `hstore #?> text[]`: Get boolean value for key path + `hstore %> text`: Get hstore value for key + `hstore %> int`: Get hstore value at array index + `hstore #%> text[]`: Get hstore value for key path + `hstore ? int`: Does hstore contain array index + `hstore #? text[]`: Does hstore contain key path + `hstore - int`: Delete index from left operand + `hstore #- text[]`: Delete key path from left operandAlthough in some ways there's a certain elegance to this, it also
sorta looks like punctuation soup. I can't help wondering whether
we'd be better off sticking to function names.
Has anybody looked into how hard it would be to add "method" notation
to postgreSQL, so that instead of calling
getString(hstorevalue, n)
we could use
hstorevalue.getString(n)
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic O�
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello
2013/12/23 Hannu Krosing <hannu@2ndquadrant.com>
On 12/23/2013 12:28 PM, Robert Haas wrote:
On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler <david@justatheory.com>
wrote:
* New operators: + `hstore -> int`: Get string value at array index (starting at 0) + `hstore ^> text`: Get numeric value for key + `hstore ^> int`: Get numeric value at array index + `hstore ?> text`: Get boolean value for key + `hstore ?> int`: Get boolean value at array index + `hstore #> text[]`: Get string value for key path + `hstore #^> text[]`: Get numeric value for key path + `hstore #?> text[]`: Get boolean value for key path + `hstore %> text`: Get hstore value for key + `hstore %> int`: Get hstore value at array index + `hstore #%> text[]`: Get hstore value for key path + `hstore ? int`: Does hstore contain array index + `hstore #? text[]`: Does hstore contain key path + `hstore - int`: Delete index from left operand + `hstore #- text[]`: Delete key path from left operandAlthough in some ways there's a certain elegance to this, it also
sorta looks like punctuation soup. I can't help wondering whether
we'd be better off sticking to function names.Has anybody looked into how hard it would be to add "method" notation
to postgreSQL, so that instead of callinggetString(hstorevalue, n)
we could use
hstorevalue.getString(n)
yes, I played with it some years ago. I ended early, there was a problem
with parser - when I tried append a new rule. And because there was not
simple solution, I didn't continue.
But it can be nice feature - minimally for plpgsql coders.
Regards
Pavel
Show quoted text
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Dec 23, 2013, at 6:28 AM, Robert Haas wrote:
On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler <david@justatheory.com> wrote:
* New operators: + `hstore -> int`: Get string value at array index (starting at 0) + `hstore ^> text`: Get numeric value for key + `hstore ^> int`: Get numeric value at array index + `hstore ?> text`: Get boolean value for key + `hstore ?> int`: Get boolean value at array index + `hstore #> text[]`: Get string value for key path + `hstore #^> text[]`: Get numeric value for key path + `hstore #?> text[]`: Get boolean value for key path + `hstore %> text`: Get hstore value for key + `hstore %> int`: Get hstore value at array index + `hstore #%> text[]`: Get hstore value for key path + `hstore ? int`: Does hstore contain array index + `hstore #? text[]`: Does hstore contain key path + `hstore - int`: Delete index from left operand + `hstore #- text[]`: Delete key path from left operandAlthough in some ways there's a certain elegance to this, it also
sorta looks like punctuation soup. I can't help wondering whether
we'd be better off sticking to function names.
The key thing is making it easy for people to easily chain calls to their nested hstore objects, and I think these operators accomplish that.
Some of them are fairly intuitive, and I think as a community if we have a) good docs, b) good blog posts on how to use nested hstore, and c) provides clear instructions @ PG events on how to use it, it would be okay, though some things, i.e. extracting the key by a path, might be better being in a function anyway. However, having it as an operator might encourage more usage, only because people tend to think that "functions will slow my query down."
My only concern is the consistency with the generally accepted standard of JSON and with the upcoming jsonb type. I'm not sure if the jsonb API has been defined yet, but it would be great to keep consistency between nested hstore and jsonb so people don't have to learn two different access systems. Data extraction from JSON is often done by the dot operator in implementations, and depending on the language you are in, there are ways to add / test existence / remove objects from the JSON blob.
Being able to extract objects from nested hstore / JSON using the dot operator would be simple and intuitive and general well-understood, but of course there are challenges with doing that in PG and well, proper SQL.
Jonathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attached is a new version of patch, which addresses most issues raised
by Andres.
It's long holidays in Russia now and it happened that Teodor is
traveling with family, so Teodor asked me to reply. Comments in code
will be added asap.
Oleg
On Mon, Nov 18, 2013 at 8:36 PM, Andres Freund <andres@2ndquadrant.com> wrote:
Hi,
On 2013-11-12 22:35:31 +0400, Teodor Sigaev wrote:
Attatched patch adds nesting feature, types (string, boll and numeric
values), arrays and scalar to hstore type.I took a quick peek at this: * You cannot simply catch and ignore errors by doing + PG_TRY(); + { + n = DatumGetNumeric(DirectFunctionCall3(numeric_in, CStringGetDatum(s->val), 0, -1)); + } + PG_CATCH(); + { + n = NULL; + } + PG_END_TRY(); That skips cleanup and might ignore some errors (think memory allocation failures). But why do you even want to silently ignore errors there?
Fixed: now it's ignore only ERRCODE_INVALID_TEXT_REPRESENTATION error.
Our stringIsNumber() could be too optimistic.
* Shouldn't the checks for v->size be done before filling the
datastructures in makeHStoreValueArray() and makeHStoreValuePairs()?
Why check before filling? The result will be the same (throwing an
error) but it saves a loop over array/hash. String values aren't
copied during parse process.
* could you make ORDER_PAIRS() a function instead of a macro? It's
pretty long and there's no reason not to use a function.
fixed - macro and delaction argument was used for development.
* You call numeric_recv via recvHStoreValue via recvHStore without
checks on the input length. That seems - without having checked it in
detail - a good way to read unrelated memory. Generally ISTM the input
needs to be more carefully checked in the whole recv function.
numeric_recv checks this, otherwise we can say that numeric_recv
could not check its input. numeric_recv() gets a StringInfo buffer.
* There's quite some new new, completely uncommented, code. Especially
in hstore_op.c.
We'll comment asap
* the _PG_init you added should probably do a EmitWarningsOnPlaceholders().
fixed
* why does hstore need it's own atoi?
because:
* our pg_atoi should work with non-C-string (not finished with \0)
* doesn't throw an exception on error
* shouldn't all the function prototypes be marked as externs?
fixed
* Lots of trailing whitespaces, quite some long lines, cuddly braces,
tried to fix
...
* I think hstore_compat.c's header should be updated.
yes, we'll do with
Show quoted text
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
nested_hstore-0.42.patch.gzapplication/x-gzip; name=nested_hstore-0.42.patch.gzDownload
� ���R ��{��(�7�)P�8"�%������V�:�_II����o�k��IJ�*����`��+I���1�]`07�``O\���g�3Z��j11�/W����O'g3����w;���|b}�2�������aX������i��Y�wZ�V&�~`m]�����?������C�X8���j�_W����c��� N��E���>~/-c���1�;�d*��{#h�u����5�o�c3�v���r�-�[#�5N�����__���3��x�����{��<��;s���2�~6Y���f�k~qi��?v�5kau��|�U3�/�����/�0�s����W�/^�
�i?;89���ZG�,?LC�5�C���CD�{q5�4����cS!|��J��M&m� ��0�I(���N������q���V� �9��c������i���IG�O_ �n:+��X���p����������'��������7��y���<?}���O/���3����qR��tQ���j~yj^M��=Y@�N�a��f���v��i��7.�������4���P��zJ,>��t���sf���uz�1��z�~|q4�<x~�Z��mct�r�\>b����d����E��:��pyq��nV��[���w+������:�d@.��2a���F�k
������������\?�]M�$YM��k������po���XJuxE��������/������=������b����w��x"�ny�|Hj�9y������E����9�u|*�<9�,Wx;���:�l�d�s��z����W��v9����P:^�a��bb��Nk� �9����VS��Z���8�Bx�n�-��WS� ���fKX@.����C/^/&`�)���7����Y��=7���
�[����jb����|��8�����S��i�T����������6j��a���o������f�}��O�������PZ�jI�eq���@�-����������(��'�P�cD���>����y!�W�I]����B[�&B/����w@�-�o��PkU��Cu�U���8�3�t���������k����TCno�R���k��}��z���5���:���12zTC���Xs������h$j��A��M�����2m�14G����j��=�x
�6�����0U]u�=�k��Zo��G=��i�#j�a��w`���s�=�g��~_�]�;�[CQ�;���>�g����"���@w�C�j��5v,Q��j}�G�t�����o���]{���:Rm��kt�������cM���@�i�g���P����v��M��L��l]�G}��3��a����7���%|{���G��m��5��>�2-w�SE
��2�������l[�@�-��0m�k����>��]� �}���v�=kd����f��:������=8O5f���������?&��#�Z\Qc���hL���j4R�o�@>�$SSMg��D
w����?�z�F|�4��6H��`0����ke'|U�d�}#[�U��s\�����C��F��������?c�t��A�9#sd���G�������;����ul�FD����x���1t�
���`������5&������T�?"W��@P{���.(
i�>�U�'���R��Cp5S���������Q
������1���=��?����O|��c���k����� �m���?Z�6t�G|Yvwh�$�����lSh}��k`?��?F��TuH�A�5��#�G��]��#|��=�m��}��
�>`��������1X3���8��%9�`8��>�� C�?z=���C���U���$g�P���'�l[���%�G_U�C�Kp����4��3TV#�Yc�f���Ff_'��:pG}��3����S�o�l�7����c����A2�1�
���G:���Ccd�������t���b���i��.��RMc`��N��
�5���V
CF�gj�>��1�~o�%|�����G��]��H������qo ���Y����}Cc`�
C���:���`���;&9����N�
a���k�nGpGCud@�"�tT
��m0V�����z�'�#u�� E5��;���T���c�4sH�������m{�1���a������
6�j8�� !Tcqz$�Cu������fk������#K����k������Ls0t _c`Z�g���k�U��������6�W:b���n�sw�v{�K��4�2�hP�"|����I�]m���*�1�Mg(��e4�;"�&8���F������A|��\�K��Tk8\�T��P���L���$���*T�E���&�
��cA���t����1��o�]���X��]� ��}[E|�a��Q����&��pd_�t]]'������>U��������c��������pD���|�}��#���qhh$�� ��4�>U0T��m}�� _�o�AI�C���$�T�6mW�C2������������K|�\�u��4�����������p����9�
�����7����0�
�o��: �N���8�}�?F��?�NA5F*�`t3]�&�k�uYnO�a _{���q�?=G���}��;���D�0���`@����j�BP��`������|h��a8�60z��
�T��I�`N�&
����uMW�c�9}��vLH�soh��;$���]��C��Z�iX�����c�H+{f������B%��
���^���P'��]{<������N���R�&��o@�*�_7�n�E���S��cu��u�[�P�k�H�����;��q��,�Y�N��)�����X�=�
����r�o&_8k�Ok`2��F#�����c\$���w���E�V�:3D�fj� ��p����|�����f�]�;��1�h��V����"���Kj��W��<��w�(���(���(\���H/�Dq._��[�8��o&����?'f�?�Y��a���l�2�X��������r3�<5M�Fj� �b2�Y���i9a+p��
�����
1�w�������|�t,hH����VIJ
�����z�N���0���h���� IfO�����K�(k�v
c�I����i}��#^��cu��{/vXCc�����i���C�Z�B-|����� �R}��AlE!B{�!B�t��v}����?����?F���@��������`>4�� ��"���|�0��e��vo��������X�
��������`���']9@�b�a���?v��?([7� z]au�u���H�����.�u��#A{���tF�P&m�*����Q��BY��,����(�a��xg �CFB�I�R ��M�������O���|zu1��bW�����W�t����t�|�s;m���G�lq�S�l�vc ����q����]��O�
��Qa�j��suE�X����3��
;�a,�M��=8::��-HG�uv���
jI�����Z`o ������N����^��\���B�-�� R�#Ru���CP������� �������Z�m�}�Oopk����G�h/����dx���U���$zj�����u��TY�5�Lo���Zj ��r.�a_�� �q?��as�x!����x o{���8m�L�
GB�X4��)J�����2��\Z�"K�Mr
+O��L� G����b�%���2W�_��
M� ������������[��9��,zir/1)�n�E T�]"$��i����������@�1�5�i��d���skKs���� ���%�"f��U_U�]P��?��(!��A��9U&"�?f��hJ�����?qwc&8UJe%��YXZ���u�_�3����t6��7��&i�-��IN��{a�c��i�&���BA�%������[.� �*)�R��l"� �O����R�.c
�R����aY���"vC6������(d�;&f�@{��dE�c���6�pE������4����g��h��4��������d%Vv�j�����C�+�@��0��>{2�M@Ao�$�$%����X�)1/�����TZ��4V���6�����p�Z"n.��w����O��/�����s�d�b~�����Yq0qu�s@R� ��G����X��Mv�0S�;!7����J9�U:@��.���m�K��Ga������ ��(�5�Z8���9YDL��
~h�Xbt�s�,�l��84�����t�!�� ���;�
`�����i�ax�@�.��f�g1�f3.2�9!�lNfKg����@��
?��V��\�"P�*��W�����7��R������UR��%�J�������7����a"�,QK��r;u���>���oe��z[��U��`+1+��
���1m���$��0���8f��f��^B���s�=��=a�/�L&�H��%vp�o��_/���::<><a��.�x�J���%�A����c����|��@=��8��r�?w����a�S8�bJ[l��
�����f��sG������#���~ CN^�;$��L�(��=Y�&3����|�;�M�\��!����>[-�0�4B���<7������c����q�K��s9sz{(F�w0��)~a9���{ �kW�d������:�d�"��}�?_�?��h��:nOK��6|}������@�^�zt��Jw����v�(n���
��#���o�A�;���Zez&~����t~�)���*J�O��Gc������,��
�N�$L���O��k���+�.�4"�H;r����-����y������n�``o���Z�����O%i������{�wU�p�yG���g�U��S��K�f�E�)\���T�������{�H0�xH\�>
�R��.�D���3�����p�l,R�K���eQ5��OZ�'8 $�"4C��)�|��x��I���\5|t�j��)2����_9M���<���J����+�5�MO�����b�U�LAlI$��Fd!G�bVc��[1k-�v��Y������ �%�T�����`��q�Vv<�Sz�
]���6�,�����AN4������Tj�M=���u�!7-��C��!�����w�F����������Q�u����G[b�N:��bA�z�u�k���~[�@g������iDpxWb�����for��J��M�'b!�V��]c�td�nK������p^��AGKF��9�f0A�txwuZ��4�u������,G������kR����qSW�����&;Q('O���!(�3s>�%�9-:c8�t#J�$����j�1�EKSt���p;�����OO�.���-�Y����
�bY�_|3(/"�u��On�I]�� ��"V
���{�r|�H��X���YW��ap��0��,�>�mv�0[�����zkk�O0]���'�����Kay����D������N�-0����;�� f����u�GC�T�����;�6m�:}GM*��/�pk��������m���h��i��*���t������kYr��n�rRn�������������}�qK�U��b�����#��I�3�$m�T"L�����az��op\��!�G��^���-V��������+o7��H�vgl~���1)4�������t���5
C���m�Dp�]��1����q��������k�Dvk&�u�>q��A�E�)@o�%p��P��b
�Jj��F%�FDq���I�g��� J���e0lm�f���D-L6nJ��x����L���(`�B�d7d�G)<(`��q���.gX�6K$q�m4{`��d��@KSb��_�O"�,L��`��(:��I��Q+ >��%�x9�MN7���oX�m��d �W��b�N�����zRs%�b��CE/��PSI��X�*
F�*�k��C�2<6�w�;��Z�^]�&��q+c4��}2��>'w�����w��b�;o�A,9�{$�7���u�m��O�1o����P���#�9��.�)��SSp��w���}��w�/�Z��>����~�m��4ed����?�>fBu#'�>??�U��L�Z������,Xf`�� ����t��a�o�T)�^���nP��/xn$������!;9���!m��L�1�0�����0: �4�_^\V�������������o/=<��3���dW�j�{G_��h��� �r~y55V�)?1���r��9o����_�6�cv%�� �
]��A.(��RX��:`Mh��2y������P)��/M�b-b���J0|q�L���M�@�q��v��8�9�V�r7�p�
���3������'/M�oGL�BK����r���N��M���n�-���k���b���6�%m��4�� � 0�� e*c)H����(���gwq��H.(�N<sM�t�� ��TAyf��,d�<�����,0Nb��?���f�l�V|��aDE�v��Yr��44��5�o���H�7��2e��("0�� ]���+��_9�
����=Z�I����KQ��)�������kE
7_bTD�[I��.�v�_��l2;�������>(�YE��*���1��ft���7IX]9
%T���P��Cd��Lf!z+��"a18��uN?Q���s�(���Y\(��"�uJ���'~A�� ���K>����G�'C���&L1������jnq��>�%4��.O��N+�H'��M�_���n�m������vs+ZOG/���3��� �@-�@A5�=�8CK�/Z��h�~�����a.���e)Q��"����m]���x ������r�P�|u����=�����C�M~q3�;e��u�`����wu��D��C�� ���\Tc��_s�� �p�.��b��Q�����8��GN�C��;���=�><������0a���P�b
����V��1�-#�u3�n��>>��gf�{�]�P��Lp�4p�����L5���m�f�:�T����f�f��/��7�\�i�y8x���#����D��*�{����)o�Ynn����}+h�rPp/��~{����:\.�}?�(��6�P)Mj���'A{3/�{�%���0���n,������5[��1����d������f�Vf�|-f���m
9��i,���{�6
��es>c���Ak�EAg��C��y��Q��������w��u���_��i_����
�����PD��54dy�����\�����O�5S=�fE�������������g+��g+���V��E�X��X���X%��i+����S��L�0�����]k����35q��l1SQ�������5������ngv�j��������Dyg���l�B�*U4_�L����-� ��}r��}/p��
.a���C�[
r�F6H��r`Z1���17���AWX�F4l����Z���Y�MI$�6gM�"�v�b���BU��s�PU��
�}�zA��]��������\;���"=Y]|S�v�K1n���i�I��S����S�9��P+a[3��`]0�i3�<�����dbl��>���}�+�`[f������m����E��:���}���ll���f��~��9����5������������j/s>���2�:[h/s���2����e��*�`�
Z���"����+y +�C�
_K��`�`��Wg�A�}��U�m4x�f0{!���WQ�\�t-��]����{WE�������{��[#�X�(���a�[� �o�-4�&x}�����}{��io�=������e����_l�Y��������%������(���2��%����64�)g����W
,g �(��VE�"�K������-��%�*N�!a�H�H6�S��b^cf���S�U�*4f����5/n���n�������/��_����uOhD�Q�9��iEe�rT��*[kI(y�&E���#��Yqx]�y��x'�:+���=�m!�\�0�r��E�V�C�8���.���w����������nh�u5��&��]�_�).���o�F����:������C|6�sVl�MF6��Y�{<W��a����fT�D�����[�g�_���~q���i�g�]���v`�J�G�d�1����?�+��|}��"m�]�l��t~q��m_X�2M�`�������Vh��E�v>���y����1��5���t_<�j��H�To��$��1��3�6I���W0��h��l��X8i�3��[�i��Q�����<To�+`m��������,���� ��� �{������@�ev�[)��on�0��^6C����^�l�q���H���n�u�-�|��p.�F(E���XcT���fw����\'�+�����Ee�\�g�6�GS�����,��
r3��>�60��OmE���?1Ss�����2�*��k!�~�+,"|���,c����<�4V����X f����j:-�����OI�em��PzLp��Uai)�n��b�m���\����_z�Q~�z��J(����nU�V�g�i�u0�9������Nm��Bm�y&W�B�+�����t��W�L[n>�������H����_����'��Fc Oz���)qT�wEu�_7��u��%�������^l~Q���c��3(�X������m������n��v���������kPT_����M��;r������X ���^=b�4lqQN4������d>�i=;<9x��,o��'�8_(�j�|�t��c��������Q����]6_�]e�+��l6w�dvy�Z��E>L��}����7,f����� �}~� M0���o�x}�c�<�6���D�OvW��r�_N/�/����gy�uE<��'������9 ~(-��h,���C�f�W4.���!����m}y.�g)�~��<��I��5I�H����hG�4O1�$��y�C�L�g|��C/,�-��~����y����������;7v��������&���v��hp+]�� �o�2��>���B �g~�E>�ys�-�����������t�R;"Ox�0����ECW��7�~8�����uK~5�F8>�H&���
Fe�����p4�8������{#�[��?�ZG>lSA�=������G@o;��P��������T��\����3��B��iiXPV�Ak��c���h���
���8���=3������Vn�~f������UU��gfZ���weg�U���3����T���8q���+��*w�{&����43]�O�33]�53-83]�SZr����wt@��5~?s��p\N�^�V�����%�Fk#m�3
������3�5�J��FGz7��v���5�� �f��V74�L�]�y�cX��s�#��A�U��l��wn�g\9^C��h�3J�Y��T<��H{o
SC�w�[d���3�oV�M���T����0J�W����q�k������D�ySe������y�f����b�)�m����!=S;��7�$t����}���S�S��'��`j=�����
�t��9�8�v�G�xT������.t<�?W��(#~B���2[aN��!ufeQM�O�d��nm�b;���[~��v�(1$�J\}��������.�I�� ����Y�nN/��������y\���J��u��`T����Lag�O��N�� �Al�DB���1���>�.MT�I��B(rV��0Q"tx�y]�o���(v���nY��%H��l$=�+v��.F����p�c���0���D�$�n=%���,�6��-+��H1GV�]Z?,�N����p1�e���G�%BXDx���%r.#A����+��#�.����R�� %�cx���K4����c�?*����B�������0�b����Oi[�I�W8.@��b��z��|�5������W��B�������L�J����U]V*�~�"�C,�p�?�����K6�9�M����q;�r8Y�����s�-����po1��N�����p<�(/K����F�nD5���6�](i��ZW�����0,gY���.������a�%����n�hg�#B���]�����=��G�X�0kK������1]:Ex}O�7����pY�o������R�{5!����Z�3��,w��������!��ze���fpu���=��k���]]�����h���Z9��
�$�����e���d����|�������Y����Kg��_���_fg�|d�d�����0MU���df;����:�����}}hbm��!.���Z�B-��k���Z�2��������;�#_@x�6���h���W^��
�m
T�d"���U���GZ��&�E"xI9N�����-eT
i��^-���fA��W�X7��A�#d�h��&NR�
��(�W��)rQn&�� ���+��� �?���<s�1� �Q�TL_i���4\kW��AZ��#�����l�ZB�ZG������:��8jq��MI��A��v�H�}��N����m����
�YL�������v�+�d��)�NBR����:�2) j5S�7�]kc���ik����h����+���<�����hm�h��g5Z6�L���[Xj����A�����hm�z�!�O�8�v&�RX�
I'��iF�3RH�������%i�Y�����=�'���ds���IVGm���v�I���l��[�v�Ui�[�J�#��T�W�����������ez���;��0�X�'_���kq'P�PBSCU��g�7|{`�[��m�5o����(��;�*�}-��A���<�c?I��������Y��[BC��>_�r�k�����m0�_��X%������
/���?ef�LY`ZyZ���$ZW�@Vb`&��,�W������
�}�U ��
3Q�Z_�Z��t_���W��2�,��������r����j_IW���^�[�+)0s��Q����.?��_�?���I�. �!�mHE���E_
�'E�q�6�N���8��ga� ���V V`�B �_�`x`@.(\o H��g1�8(����i�+����?����P�u�4v?}����� 2mf.CA����<������v�^��<����`>z$��i��Xlw��Q��i��Yh���V3-��W�W�L���/��K���
Q��g��7���9�7H�J�W�� ���_��_��"�"_�(|�O�:
����
n���I�
/xD���uzt[L�*^�|�h�SJ|"^[��������)�;�V�*]�O�p&�����OP�R�P�����M,ou=�O��-�Q���h�ua�N����%��K���\e�S�� {�I�Tv�$�V4�t/��b�p�����\�A��5�����2�q]�pZ���<�^�kca���q�\����)=�>���O���+}x!19��t��1�2P���W��~O�:����Eb]z��.�2��,��U6���GW�Jm*��L"�Fl��YA�����::���,?L�A��R������T�H����P�sW����X��A����rjLfl�����\��d��������_Bq�-����`�sc��'{ztxpr��yr�����W;�?�|�~��~����(x����o�a���&h�n�����B�������d���~������:+��
����*t��?����q0��v����~}yx�����W��*�b6���zy������S�L���_~��������C��~sxtp����;�����N���}A���^<�Y<D������O��zt�������3)���1f)��E)�+P�����fS�Q
V(D(B.,�
���8���+���F�+��[��J��n����;���fQ\Ru��WM{1
y"�)�A����'�,��H���Mq3�N�:�8B{I�&����7�
r���s&�cZ�n�����<LKQ5[���m��,�U���Z�#���2���q�Rg��'�C�#���(���� |zp|��)�[��;��8�91)���i�\-���i����Sq�����6��{5J�E;�4MZ:S|�_�x%��k>���4��s^:�@�Q^��{k>4�T�����L���/�]�j� U�E�:/B-gS�� $����
�&�j��4�����bc����R� X�O�,p` �Y:��[�c'8U;�y�D��@�l9���Te@�*�M���8��h�J)���B����
������N`z|x��'Psk���q�b!r "� ���r�u+�� v�^rYgq1���G���Q�n��|%�y�f�c/q���N�Y�A�?�<��]�*J�����,nK���"��&~U��o�2�(�0���2��?������/V�x��i,��/���\b)���������V��I�
W����*��"�{$'RN�����)H�~�r7T���}H�m_���2�����g��\G�ez�����0
�q~ 2� ^������9~��9��qD�`������ �7>��&>�Rh]\6�R��)+�%q.�n20�l0UF�L/���D-�Q����*[|������v&������v�����h*�k�
������$��r��1l�mpm�S��"�Pd����~}y"2�%%)�2����eV����<�Z�H�-�fE>'���n���;���i��nO�C��������Vi�?��}M�w�����?��������=�65��=�vhO?�R�b�&>�"*�����q����W��i��l[����V5������1�-��7������]����Nf��c����Kc����/^��:x��������>jm���_O��#�o�L�#/A$��G�O_�v�F6���z�D��/�0���9����nf���Y,'���=1���C��99�)EF���C8�)�F��P��h�C[���N������)^N'��,����������G�m�F\��R�"��T�:{�D�g,�D������N6�~����m7�!TIs�^D[����E�H^l��!U���P�0�su��$3��@�*��V1f��>3��M0c��w2s���B ��!�h��}�X��L!������a�kVr�IA!�M�A��@���d��]T���M��
�9xbCh=yx�J����e�S���M�
&z�T�
ttF�i�W;�4k�P���,���c��b�_=}M-!�}����k�>~��� �;��O*!�n����c�y$a������0�?[��:���ae`"��{�UF���^{������� ;@�
�,�"����HnKBn���[>vk�����X4�cy����6c���(jY+0��U�����y4��e �F��T��� C,��CQ��8�y�G5u�u�j)*��G�.pd(��^�dQ�E�5�[<-�l�x���Vs�����ZL>U'���B�7�P��M#�@3T�&�[��3"�h%��Ah��\�����,�U�u)��x���h�X`Y[,��b��G<�,6HG��r�P��
X^�/����� w�a�u��VI�>x�g�bP+�<�w�~��~�?�_�G�������q�����|���I��}���3K_v(�������{�>�.��Y� v��u)?[�����O��|�.��5(������m��
��~h��L+
����udn�<u�\<��I��`��|�sF�F��b��������q���������I� <��3'��0e��Rrgrzg>�!�:w(0�XL08d~�,�FC��a����
��{cf3�W3{n]��v�� ��tf�V���
���di������~>H�Z3�Z]��q������}��o�����Z?�F��f�����0�}�aLW)����72i|�d��@x`�t%���."�$}�[!0M����)��O�A�Y� ����]� �2�;��o+<K�w)�nC&I�a��U��P��m{qd�X[*���|��V����5��g��~�A�F|�<��P���7L����3� ��WR�k�1�Vd9�)��8�);j���)l S�1����D�j�����$��<��,kY������qdg �l&�,Lp��������i�^��r)�a�c��)-�����A�����@W������@bb�_^N'+���75��g_��%�~ig�����\����iC�ga\�H��f��������$���{=��G�5�E5U�����T��VR�+�n�����w?��%���(?d��Q������I*K�G��"����B�c���� g���x�1��U����b�����P�r'� �3ze�2�BR��q��w=�'��CP�l7������*~��[���m���JY�Y��-ncK��R6�l������B8 � d������2�+L��yP���v-n�C� ��Z<5��sT�W25h"+��;��
z A�
�E���O�
��|$3|x���m�������9<����C��=<�g��dCo���w��C����C�{����e��PJ*Q_zx�_���G=<TZ���CUROn-mjVR�*9'�J��W���\�J��W���R��u��R��������������7�z�\�}��9,v}��r���9�,B�k�z����z�������v�%&����e&�+'�_9��7��N��P�����&~^�"������P��*�B��aMfL�����de8�'C(�5�h��<U����=�.��Q ��n^N�J(Tv���,�����$������M�����aq�[����H�����e��G�xT_��#��_W���"e�� ��$��T@����*���E��,�He�&�Udm�0FA�*R�HV�$;����l����/�A/3�H���}W�� ����X�j#�������&���}e7idf�)9���*��$7Pvk�U<%|Zn�V^n����b��|*(�N
~n�r��An�����r����B���b�~?7Pu�e���dn�L>Es��[c�ryw2K���
����
T�8/7Py��Y�:�(��hn�r4��@�gc��@%��xA�RNg�{�*����Z�>���#\��/x�$CSKD�o���34U��o���"�����
��� ����y&����P�i%[����N�sZX��������\��H�����`%c11X�n�LV���}>��d�g���y�u)?[��db���O��<��l�kP.IV�H%+�|��|o�zn%��y��������`~;��`��db0�����-���Nl<��3'��0e��`rgrzC���m����6��U"1�l����-c�J��JJ����$�7+&�x�,����`'0M�����m��'���,U�����.S�g�������
��~�!���M$kI���O��$k���$��Z��`�����Y�$Ki#��J��<1X�AV�,���,����D�q�D����;$��%��%��Qjib�
�%+y�:�,y�:�,e���l{��6�����j��`�G"31���OO���$�:%�m�v�hb��K������W����`��Y��$�3��)'1X`�2�e '��m%1X*�2��R�J�Z�`b���U��,�,P��`� ,
�wD��`�0�����$S�����g�6�)l��m&S�V�������Z��F���-er���_X|�3�%�������La���)���)Lb#h*gK�.g&�4�K�
��}�C����j�t�g2��+R���(�Jv�Tu+�g�*L��[Y������H����U���%�������i����I��7N��tI{��$�l����S��,��/���,zic�$�m�f���6I�b)l��p$�@���gQ���yjE��H�8�
�����mY]s0��)b����r)�e0����1�b)�o�NK��0i�n^�V����`������aI�eX:�%��<���b4��1Y�=b���r�!��?�/��;�5�j�Om����?��iO��k�p�s�1��~��r�0�<�!���z���QU��
�E~���sbr_�V_s&�3����g����?���0x>�Y�+�au��l�9����G���|}m2s��2T�j5�.R��7�pE�N/S��po��=��!`|�w�@�"`��X�����b(������"��oF��E�NW���tM�"��!@#(���Z���t��^�9���v'���;m�?�:9�����O/��O��i$��J�` 5�"��"o^�rp�w(����O�
�j���e����Uk��D!� ��8������
��[M� L�n(���_�T �#+v�A!=�O�zk ���������������a�� )vr��a:`��Z���~]�
V��GG�3��==xyp�U�v9y�VLr��`�iE��\��"���&�2IZ#���%(�����<a�Z�?�X��1�m6yw�,�]��� ��0��K��`�M �Ba0���aY� ���`>�NF���+d_����f��i�5���^����������X}T���t*B�n��|.�~��T1���&��g�D
���A���98jA�J6q���b��O>�"OG[���D�J5�C� NEd�O������� ������o��d�`�ga`���A���M����z��ITJ�������7��m�mk��18/_����ACx��hC�h������h����ym�4l�&x���7q����|�:�n�[u����dS�����s�?�o0]<�����pf��`�� ���pm,����4��5��sjt2�y
(��`}<�O��a�C���9�\`�����������r������" {'�b����0^����h���p 5^���-�^8o��S����Z
��f`0�a�����W�+p�Uw,���� ��C�a}�N��%�\S@ 3'+�b������`�eE#%�KM��%����2,��@Q�a��#��=���|��q���h��Z�(O�� {3?:0�X:���%s����K�.s}p'����c����X j��������7���� a���qWT��Z]a ����w�t��������������:��b)��((|�Z��N���D���B�kT\���|������-/�E���R���s�'N�O�z�����������y�����U�b,R����/oN~�m���������<�������?z��$B �Q`�|����k������ND�o�7%��8>E/w������ i��[$�)
r���fC
r�4Z�T���g(�Z�j�6��h���=E�����3��k|��t��2��&k��{����I�3cuu��Y���01�_�q�h�t���2��m�}a�<#HSs2s-\�Y���c{����g��
jL���I�oo� �2�q�1< �7'G@ t&��#�yk{M$��4�d����
U����a_D �!.{<815�&�Rg7e4=���
���0|6`�8U@����
~��q/�
4��{
x���K0����� t���s��I^�j%[�z���V%�}�y~��(�8���2 �C����#� �[�����L8>�N_�b��AQOq��(��/bY���
Aqz����l�q��gN0�w�������:She ~��7�Fl�0�0�����'��D
y$��6����v�I0�#��P�'�e�W?�����'�����o��"��qJ��h�-��q�����*�;7��.����� �bW�������������X!g�AX^��C���w5_����.��� p�g�S��g��{
w��+�^ ��fx�i���C�Y(�����B8�j���a�9��.����X��|G���������O_������/
�D!�BI!.(���U���x�
�}�"�k����b��v�\X�7���)Kc�}!`�V��5��C�Di���{�Qm�Z�'|�5��m����&ZI�(�t8IH��M�Q?C-�o���������w��N�NWd$�|���?}��/�_]�l����tF����������/x�����g����:(���%Q-i!j=5�$��<�p�2l��V8/�^��S��R��+�#�������B<{����)��
�5����vL�(�P��F
URA������&KJ2� a���^��p���@�>9SS�z�[��>W=B\����W�*U��!-��N�&7������`3���&�J���#���9���_�f�bn�
����W.��4�A��%Q5xM�R�<���;�d�y?���X
����`�mH����2y-���q�$(�x
�����LE0 ���"�����7��@Df^�>���4a�t�J8O����L6����X��`k�@/%��<�)@3�w�-"�Oi.��}x�0"Qp/E!\.��C�U��bN�!�Y���:=�� =��x|��
�
>����+-i���$66/k���.K����F����k�P��1�Gb��J>�hy���X��7,�#�u;��m��I�4(?����-2�#� �������|��^�9����n)�
N4.`���^�\��t��9T��� sR�Ej�����0r������w��(!e6��%DU����;���MN`�90$?�=��s�@��p8H����>0=A'�����N��!|j�I]t���G�X,��A�
#��R�M������d�6w�p���A��c��b��sr�� ��~����IRq7>��t)��Z����W3���b�5�2�������V<T@kFK��{��+q���� /��������W|�L��a�z&��V4U
�v��%,��� ,�Q��z|;�c��|b���Gc���V��f��4����C%��k���7���{��)�5�gS����[�,
}����_g���O2��C
Ql�e*��e���@�h5����'%X�5�k(,���) ��CU/'�����!(�bfa�kD�eDD&���9(��d?��1����G$N�"&������?�0���"����-�k�,�r��ph�%Jz3�4�y�5�L"���r#�b���������gly-���������@���Q���5���}C���� ��S���)w��c;�U����+�W?��8�����P������
�P�0��T,,���)��
��b��1��Sv:��)��
��p ,����O�����a��^Xn'�x33Q�A�d�`����[ ��G�z�7:e��6�����1��'���i��*���4�}��\y1LB�.�o��/���Gb� 5y�;>���
�����#7�����{3~~�.�����D����&��F.�)@��[�z_��9V�k�N��W����/����Z���i��=�m�6�zT<J�Xl�����T�./���2������f0�&����;���;7/�YC��r3Y�H����'�D ���[��x����7���� �qxdoN�\����,w��i�/V<��N�6�5�_��<
&)|���y�o�����]po�r��'\
��_��7��b���^�?$�Z����R_8h���
�����>�H��G�NF�n9(*&�1"�gt�q�����`'�6��(�`"�h���e��)�&�yU���8k�`�gdkj� B���Y��a��&�CE�������Q�����~1���>"�R�
u�Z��'` &�x��L���'��`rl>� �[�w�+ `d��n�x^����Q�R�1���k�����0�e���j!�q6?]^Y� ��c�-gfO\�������F[�u���a)�����0�G�>��������,LiJ[:|��O�p.��0��XV�Q���r]T�r�]a�)�
�\��������lO��;H4y��"��^�0�9�
�qGc������6� ������ c�"3�������;�� �d���>7"�mO�� L$Z��Y��Q�8-��c�.��^���{�v�zS���o��$��z�+N�Y2�- �I@4�OU�{�iG ��R.�AW#��Qm�W��X 2�Z��7�x���=--�L����$�����4C+4�A������?��6�������a �"�;������|��������aAYu�)) �M�=�������a���?0u:��+��.���|��q��+\_�8;s��;�+��z�:6���=�L��|p
;�^���!��z�<t0�6KFfD�#�o�X�+"z`�g1���ah"$�VZR��rYa�(9�\8P��xc��'�^$N��i�V"�R��a�60���J�-yZ�����h�R+����0����0�H�$����V�� |�]�V�.Pr����Ax�GT�B�
�)�J�)I1 �/�����W�L�;m�F��:|P����>�A�����t{�a�Hw(�W�C�v�y�N+��������|a�asE���o����}���$�����(�E��R~E�L��2*������S��<��X��m $��>��,G�_���m��6�/H<?����M��yvx����D���{���j����gH����G��#>%����q\����{���p�pq����A��pe��/�mpA��6������P�n(��}��>�]�����Xl^�V�I�?$�4T<zh�`��}��g��� �&FX�jN�9� �$9����?K
���G�I{��b+���w���(�F�zv �����6=I�������a?>���%�Ve��|��om
�P\N� �W?Ef�/��kH�\��A�M������� t�����J�2/�^�"w���n�e��[~ZJ���~>�<������%�+y=���n\�����(��tG��u"e�+��c $q�������D�������.o�Z�y 2��8�q���^��������"��eN���3���6+R)��Y��I1����X����d�1Y��^6U�T���[���Ef��~�4��@(��ZE�x^?g?��KF�xN�
f����^��M�� < �y5�{�Y��^�z�������Y�joz5�]|5�������bV[��
ykV�.X�cV����So���KU���/^����7��L���ZM��KfJH{��E3�)#���������,x����Ea���0p�� ������`���_��w"