also referencing
https://bitbucket.org/zzzeek/sqlalchemy/issue/3034/use-my-own-bindparam-for-querylimit
On Mar 21, 2014, at 9:39 AM, Ryan Kelly rpkell...@gmail.com wrote:
I see your compatibility concerns.
Let me see if .offset() without .limit() does the right thing.
-Ryan Kelly
On
I see your compatibility concerns.
Let me see if .offset() without .limit() does the right thing.
-Ryan Kelly
On Thu, Mar 20, 2014 at 10:39 PM, Michael Bayer
mike...@zzzcomputing.com wrote:
the int() catch here on limit/offset is something we added due to user report
which raised the issue
Hi:
It seems that the argument to query.limit must be a number. However,
NULL (which I imagine could be passed by the null() construct or as a
string) and ALL (which, I suppose could be text(ALL) or
literal(ALL) or just the string ALL) are perfectly acceptable
values on PostgreSQL.
Is there some
LIMIT NULL and LIMIT ALL per the PG docs at
http://www.postgresql.org/docs/9.0/static/queries-limit.html are the same as
omitting the number.These would appear to be syntactical helpers that you
wouldn't really need when working with a select() construct (unless you're
trying to get at
Redshift needs LIMIT ALL to avoid attempting an optimization which
causes it to crash.
Note that OFFSET 0 is the same as omitting OFFSET, but it acts as an
optimization fence. This, I suppose, is a similar thing.
-Ryan Kelly
On Thu, Mar 20, 2014 at 5:38 PM, Michael Bayer
the int() catch here on limit/offset is something we added due to user report
which raised the issue that it's a security hazard, back when we used to render
the given value directly in the SQL without using a bound parameter. We fixed
both that it allowed non-int values as well as that it
