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