You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using asyncpg 0.10.1, Python 3.6.1 and PostgreSQL 9.6.2.
I started to hit a strange problem this morning, with a query involving a DateRange column. I was really surprised, because the query is almost equivalent to several others, and it took several hours to distill the even more surprising script:
importsysimportasyncioimportasyncpgSQL1="""\SELECT r.size AS "Size", r.validityFROM shelf.attachments AS aJOIN shelf.resources AS r ON r.id = a.resource_idWHERE a.object_kind = $1::notable_t AND a.object_id = $2::UUID"""SQL2="""\SELECT a.id, a.resource_idFROM shelf.attachments AS aWHERE a.object_kind = $1::notable_t AND a.object_id = $2::UUID"""asyncdefrun(order):
conn=awaitasyncpg.connect(user='user', password='password',
database='database', host='127.0.0.1', port=5423)
iforder=='good':
stmts= [SQL2, SQL1]
else:
stmts= [SQL1, SQL2]
forstmtinstmts:
values=awaitconn.fetch(stmt, 'risk.Company', '3332bc6c-3319-11e7-a713-0242ac120002')
print(values)
awaitconn.close()
defmain():
loop=asyncio.get_event_loop()
loop.run_until_complete(run('good'iflen(sys.argv) ==1else'bad'))
if__name__=='__main__':
main()
With an arbitrary argument the script executes the statements in a different order, and I get:
$ python test1.py foo
Traceback (most recent call last):
File "test1.py", line 47, in <module>
main()
File "test1.py", line 43, in main
loop.run_until_complete(run('good' if len(sys.argv) == 1 else 'bad'))
File ".../python3.6/asyncio/base_events.py", line 466, in run_until_complete
return future.result()
File "test1.py", line 35, in run
values = await conn.fetch(stmt, 'risk.Company', '3332bc6c-3319-11e7-a713-0242ac120002')
File "/tmp/apg/lib/python3.6/site-packages/asyncpg/connection.py", line 340, in fetch
return await self._execute(query, args, 0, timeout)
File "/tmp/apg/lib/python3.6/site-packages/asyncpg/connection.py", line 651, in _execute
return await self._do_execute(query, executor, timeout)
File "/tmp/apg/lib/python3.6/site-packages/asyncpg/connection.py", line 672, in _do_execute
result = await executor(stmt, None)
File "asyncpg/protocol/protocol.pyx", line 162, in bind_execute (asyncpg/protocol/protocol.c:57595)
File "asyncpg/protocol/prepared_stmt.pyx", line 95, in asyncpg.protocol.protocol.PreparedStatementState._encode_bind_msg (asyncpg/protocol/protocol.c:53417)
File "asyncpg/protocol/prepared_stmt.pyx", line 162, in asyncpg.protocol.protocol.PreparedStatementState._ensure_rows_decoder (asyncpg/protocol/protocol.c:54254)
RuntimeError: no decoder for OID 3912
In other words, it seems that the source of the problem is not the statement itself, but rather when it gets executed.
If needed, I'm willing to try to reproduce the issue with plain data types: above, the notable_t is an enum defined as
CREATE TYPE notable_t AS ENUM (
'risk.Company',
'risk.CompanySite',
....
)
The text was updated successfully, but these errors were encountered:
set_builtin_type_codec() flushes the codec cache, so internal codec
aliasing (for enums and fallback) must use a version that doesn't
kill the cache.
Fixes: #133.
set_builtin_type_codec() flushes the codec cache, so internal codec
aliasing (for enums and fallback) must use a version that doesn't
kill the cache.
Fixes: #133, #122.
set_builtin_type_codec() flushes the codec cache, so internal codec
aliasing (for enums and fallback) must use a version that doesn't
kill the cache.
Fixes: #133, #122.
I'm using asyncpg 0.10.1, Python 3.6.1 and PostgreSQL 9.6.2.
I started to hit a strange problem this morning, with a query involving a
DateRange
column. I was really surprised, because the query is almost equivalent to several others, and it took several hours to distill the even more surprising script:Executing the script without arguments, I get:
With an arbitrary argument the script executes the statements in a different order, and I get:
In other words, it seems that the source of the problem is not the statement itself, but rather when it gets executed.
If needed, I'm willing to try to reproduce the issue with plain data types: above, the
notable_t
is anenum
defined asThe text was updated successfully, but these errors were encountered: