Re: register_hstore does DB queries, does not play well with async connections
От | Jan Urbański |
---|---|
Тема | Re: register_hstore does DB queries, does not play well with async connections |
Дата | |
Msg-id | 4D623123.4060804@wulczer.org обсуждение исходный текст |
Ответ на | Re: register_hstore does DB queries, does not play well with async connections (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: register_hstore does DB queries, does not play well
with async connections
|
Список | psycopg |
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
В списке psycopg по дате отправления: