Re: hstores in pl/python

2010/12/14 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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.)

we can search a OID function descriptor. If you know a name and
parameter's type, then isn't a problem detect function. It can be
based on FuncnameGetCandidates.

Regards

Pavel Stehule

>
> 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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>