Re: hstores in pl/python

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: hstores in pl/python
Дата
Msg-id AANLkTinmDdNuhq3eiko1G5=A-TrYvDUnzT=aPhsfV+TV@mail.gmail.com
обсуждение исходный текст
Ответ на Re: hstores in pl/python  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: hstores in pl/python  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: hstores in pl/python  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_execute_from_file, patch v10
Следующее
От: Robert Haas
Дата:
Сообщение: Re: rest of works for security providers in v9.1