From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jan Urbański <wulczer(at)wulczer(dot)org>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: hstores in pl/python |
Date: | 2010-12-14 03:19:21 |
Message-ID: | AANLkTime8UZ9eMkJKKkg7X_oCQcxuFaGmS1heG=PJcww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 13, 2010 at 10:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I agree with that in general, but we do not have a very viable solution
> for letting independent extensions interact.
Can we create one?
> It seems like what we need at this point is a detailed, non-arm-waving
> design for what Jan would do in pl/python if hstore were in core. Then
> we can look at it and see exactly what we'd lose from keeping hstore out
> of core and then decide whether it's worth pulling in.
Sure.
> We should also consider the JSON alternative that was muttered about
> upthread. There's more than one way to hash a hash ...
Well, that's the thing. If we decree that Python dictionaries map
onto hstore, does that mean they DON'T map onto json, or Pavel's
hand-wavy proposal for associative arrays? Because from 10,000 feet
it sure isn't obvious why hstore would be preferable to either of the
other two, except that it already exists and the early bird gets the
worm.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Itagaki Takahiro | 2010-12-14 03:21:56 | Re: pg_execute_from_file, patch v10 |
Previous Message | Tom Lane | 2010-12-14 03:17:14 | Re: hstores in pl/python |