Hacker News Reader

Comment by drob | Hacker News Reader

Augh, I needed a hashmap in plpgsql last week! It's the worst. Best I could come up with was an awful hack in which I left stuff in a table with columns (key, val, invocation_code), where the third is a UUID specific to the invocation of the function. (Disgusting! I'm not proud of this.)

I'd pay (one upvote) for a blog post with a better way to do this. If one doesn't exist, this might call for a postgres extension.

View on HN

The extension you want is hstore. It allows you to create variables and columns of type hstore which is a (String -> String) hashmap. If you actually needed something more like (String -> Integer) or (String -> Decimal), then you'll just need to cast any values on their way out of the hstore.

http://www.postgresql.org/docs/9.1/static/hstore.html

I guess we could do it with hstore. I wonder what sort of performance I'll get on it for a hashmap workload. Hmm...

Compared with adding multiple rows to a table to simulate one local variable? I expect readability and performance will both be greatly improved, but... it's hard to offer a good recommendation without knowing what sort of calculation you're trying to perform.

I've found performance pretty decent when using hstore with indexes. You should read about what's coming in hstore 2, also.

Do you have a good description of hstore 2? A google search found a few references that there is an hstore 2, and that it might be related to PG 9.4, and that it might allow the values to be non-string, and it might allow nesting... nothing very clear.

This was actually the last thing I was looking at before throwing in the towel and moving back to the app server in the interest of getting things done. I'll have to give it another go some time, thanks!

Reply on news.ycombinator.com