-
-
Notifications
You must be signed in to change notification settings - Fork 502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The adaption of nested empty list in 2.7.5
#788
Comments
I just added a test for this regression: 1fe9f1a |
For reference, the change was needed to fix #325. |
Observation 1: the previously returned value was wrong:
This is an array containing the string Observation 2: postgres just doesn't do arrays of empty arrays:
at this point I have no idea how we are supposed to fix this bug :\ |
We can determine if the variable is just a nest of empty arrays and send a single one to PostgreSQL. We lose round-tripping but the value is lost anyway. |
This sucks so much... /cringe However it's valid syntax. |
...somehow. Postgres doesn't support them and converts them into a simple empty array. However this is not really our concern: the syntax we return is valid. Close #788
yet another observation the constructor:
this is the same failure of So, even the test proposed doesn't work: curs.execute("select null = any(%s)", ([[]], ))
self.assertFalse(curs.fetchone()[0]) this fails because it requires a cast next the placeholder. But it sucks because normally you wouldn't require such a cast: array of non-array don't need it, so you risk a statement working with some values (non-empty lists, empty lists) and failing with some peculiar ones (lists of empty lists). On the other end, if someone has a python list of uniform objects, e.g. ints, I don't expect them to put an empty list into it. In other words, if the |
...somehow. Postgres doesn't support them and converts them into a simple empty array. However this is not really our concern: the syntax we return is valid. Close #788
The adaption of empty list is different in
2.7.4
and2.7.5
The result of 2.7.5 will cause
malformed array literal
if it used with=ANY(:arr)
The text was updated successfully, but these errors were encountered: