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:08:15 |
Message-ID: | AANLkTinmDdNuhq3eiko1G5=A-TrYvDUnzT=aPhsfV+TV@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Can we arrange to pg_dlopen() the hstore module instead of linking
>> against it directly? Seems like that might let you use it when
>> available without making it a hard requirement.
>
> 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?
> and (b) how do you identify which type OID
> is really hstore? ("The one named hstore" is the wrong answer.)
Ugggh. This issue of needing to identify things by OID keeps coming
up, and it bugs the heck out of me. As an internal identifier, OIDs
are great, but the fact that they leak out and people need to care
about them is really not good.
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".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-12-14 03:10:27 | Re: rest of works for security providers in v9.1 |
Previous Message | Robert Haas | 2010-12-14 03:02:11 | Re: pg_execute_from_file, patch v10 |