2010/12/14 Robert Haas <robertmhaas@gmail.com>:
> 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.)
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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>