Re: hstores in pl/python - Mailing list pgsql-hackers

From Robert Haas
Subject Re: hstores in pl/python
Date
Msg-id AANLkTinmDdNuhq3eiko1G5=A-TrYvDUnzT=aPhsfV+TV@mail.gmail.com
Whole thread Raw
In response to Re: hstores in pl/python  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: hstores in pl/python  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: hstores in pl/python  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_execute_from_file, patch v10
Next
From: Robert Haas
Date:
Subject: Re: rest of works for security providers in v9.1