hstore parser

[GoogleCodeExporter]

hstore value is returned as a string, a javascript object is obviously 
preferable.  I'm looking at writing a parser in js for now, but wondered if 
this could be handled by plv8 natively.

current output:

psql=# do language plv8 $$ plv8.elog(NOTICE,plv8.execute("SELECT 
'a=>1,b=>2'::hstore;")[0].hstore); $$;
NOTICE:  "a"=>"1", "b"=>"2"

desired output:

js obj: {a:"1", b:"2"}

Thanks

Original issue reported on code.google.com by t...@blit.com on 27 Jun 2012 at 7:14

[GoogleCodeExporter]

Yeah, hstore is always a headache to PLs and I wish it were a built-in.  I 
don't know about it so much ATM but Peter and others are developing 
"transformation" of type conversion between database and PLs. I don't 
personally like to take special treatment for hstore which is not a built-in.  
If we do it, what about type-X and type-Y?

Original comment by umi.tan...@gmail.com on 28 Jun 2012 at 2:01

[GoogleCodeExporter]

The real problem is that since hstore isn't built in it doesn't have a fixed 
type Oid. At the developers conference in May I suggested we have a registry of 
known types so that we could in future deal in confidence with non-builtin 
types, but there is nothing there yet. Until there is I don't see any realistic 
way of dealing with this. I would suggest you handle this in user code. 

Original comment by AMDuns...@gmail.com on 4 Jul 2012 at 11:12

[GoogleCodeExporter]

proposed enhancements for 9.3 include an hstore function to emit json. so the 
workaround in this case would be to pass an hstore argument wrapped in this 
function, or call it from inside plv8.

Original comment by and...@dunslane.net on 19 Feb 2013 at 2:42

[GoogleCodeExporter]

So no fix needed here?

Original comment by umi.tan...@gmail.com on 20 Feb 2013 at 8:17

[GoogleCodeExporter]

As per comments, no fix needed.

Original comment by AMDuns...@gmail.com on 9 Sep 2014 at 10:21

• Changed state: WontFix