Thread: register_hstore does DB queries, does not play well with async connections

Hi,

as per $SUBJECT. If you have an async connection and try to do
register_hstore, it does a query to get hstore's OID, and does not do
poll(), which results in an error in fetchone().

I think the solution is to allow people to pass the OID in
register_hstore and document that you have to do it if using async
connections. Currently I'm doing the select myself (asynchronously) and
monkeypatching HstoreAdapter's get_oids to just return the OID.

BTW: the query assumes you have hstore installed in the "public" schema,
which might not be correct... How about allowing passing the
fully-qualified type name to register_hstore?

Cheers,
Jan

On Sun, Feb 20, 2011 at 10:08 PM, Jan Urbański <wulczer@wulczer.org> wrote:
> Hi,
>
> as per $SUBJECT. If you have an async connection and try to do
> register_hstore, it does a query to get hstore's OID, and does not do
> poll(), which results in an error in fetchone().
>
> I think the solution is to allow people to pass the OID in
> register_hstore and document that you have to do it if using async
> connections. Currently I'm doing the select myself (asynchronously) and
> monkeypatching HstoreAdapter's get_oids to just return the OID.

It seems an useful feature. Added
(https://github.com/dvarrazzo/psycopg/commit/143dc2e9).

> BTW: the query assumes you have hstore installed in the "public" schema,
> which might not be correct... How about allowing passing the
> fully-qualified type name to register_hstore?

Is this really a real use case? the 'public' schema is specified in
contrib/hstore.sql so you would need to hack the installer to put the
hstore somewhere else. Even if someone did this, the oid parameter
would allow to specify the type working around the hardcoded schema in
get_oids. Then there are the casts: I assume if the installation
schema was in the search_path they would work anyway, but I haven't
done any test after seeing that the installer always put hstore in
public: if installing hstore somewhere else is really something people
do we can think about that. Otherwise I would avoid further
complicating the interface of a function with already 4 parameters.

Thank you, bye!

-- Daniele

On 21/02/11 10:24, Daniele Varrazzo wrote:
> On Sun, Feb 20, 2011 at 10:08 PM, Jan Urbański <wulczer@wulczer.org> wrote:
>> Hi,
>>
>> as per $SUBJECT. If you have an async connection and try to do
>> register_hstore, it does a query to get hstore's OID, and does not do
>> poll(), which results in an error in fetchone().
>>
>> I think the solution is to allow people to pass the OID in
>> register_hstore and document that you have to do it if using async
>> connections. Currently I'm doing the select myself (asynchronously) and
>> monkeypatching HstoreAdapter's get_oids to just return the OID.
>
> It seems an useful feature. Added
> (https://github.com/dvarrazzo/psycopg/commit/143dc2e9).

Cool, thanks :)

>> BTW: the query assumes you have hstore installed in the "public" schema,
>> which might not be correct... How about allowing passing the
>> fully-qualified type name to register_hstore?
>
> Is this really a real use case? the 'public' schema is specified in
> contrib/hstore.sql so you would need to hack the installer to put the
> hstore somewhere else.

Well in 9.1 hstore will become an extension (because 9.1 will CREATE
EXTENSION and friends, yay!) which will make it easy to install it in a
different schema. And lots of people on pgsql-hackers said that they
were installing contrib modules in different schemas, if only because
they habitually drop the "public" one for security reasons. And then
there were people saying that it's possible to have a *different* type
named hstore accidentally installed in the public schema (sic!), so you
have to schema-qualify the names.

But you're right, you can always use the oid kwarg in that case. I think
we could just document that the adapter assumes public.hstore and if you
have it elswhere you should use the oid kwarg.

Cheers,
Jan

On Mon, Feb 21, 2011 at 9:32 AM, Jan Urbański <wulczer@wulczer.org> wrote:
> On 21/02/11 10:24, Daniele Varrazzo wrote:
>> On Sun, Feb 20, 2011 at 10:08 PM, Jan Urbański <wulczer@wulczer.org> wrote:

>>> BTW: the query assumes you have hstore installed in the "public" schema,
>>> which might not be correct... How about allowing passing the
>>> fully-qualified type name to register_hstore?
>>
>> Is this really a real use case? the 'public' schema is specified in
>> contrib/hstore.sql so you would need to hack the installer to put the
>> hstore somewhere else.
>
...
> But you're right, you can always use the oid kwarg in that case. I think
> we could just document that the adapter assumes public.hstore and if you
> have it elswhere you should use the oid kwarg.

The issue has been raised in ticket #45 too. And I realized that is no
problem at all to register the typecaster for all the hstore OIDs
found in the different schemas. So no additional parameter to specify
the schema: the register_hstore in 2.4 will just work (tm).

-- Daniele