Re: hstores in pl/python

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

In response to

Responses

Browse pgsql-hackers by date

  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