Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> That doesn't deal with the issues of (a) what is a reasonable fallback
>> when the module's not there,
> Well, if you were passed an hstore argument, and hstore can't be
> loaded, wouldn't throwing an error be fairly reasonable?
Obviously that case won't arise if hstore isn't installed. However,
you might want to make use of hstore in other ways, like translating
a hash *to* hstore. No doubt you can always lobotomize your ideas
to the point where no such case can occur, but that doesn't seem
like a pleasant restriction in general.
> I'm not super-eager to suck hstore into core. As contrib modules go,
> it's one of the better candidates, being time tested and popular. But
> I'd really like to think that standalone modules are a viable way to
> distribute software, and that issues like this have a better solution
> than "pull everything into core".
I agree with that in general, but we do not have a very viable solution
for letting independent extensions interact.
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.
We should also consider the JSON alternative that was muttered about
upthread. There's more than one way to hash a hash ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
