"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> "Jonah H. Harris" <jonah.harris@gmail.com> writes:
>> Don't we have any similar usability cases in the system like this,
>> where negatives are not allowed only for the sake of it being an
>> insane setting? I'm tired, but I thought we did.
>
> Yeah, probably. It's the kind of thing where the call is close enough
> that it might be made differently by different people.
>
> After thinking about it for a bit, the only downside I can think of is
> that throwing an error might create an unexpected corner case for code
> that computes a LIMIT value on-the-fly and might sometimes come up
> with a slightly negative value.
See, that's what I was thinking when I wrote the OFFSET -1 LIMIT 2 test. If
that produced 1 record then I would say it avoids a corner case for user code
which would have to special case windows which hit the beginning or end of the
data set. But given that it doesn't work that way anyways user code already
has a big corner case.
The argument for errors that I see is: Having a useless non-error behaviour
locks us into keeping that. If we one day think of a useful set of semantics
we can't just silently change the meaning on users without a transition period
of generating errors.
For example we might want to implement negative offsets like above, or if we
want to implement negative limits as meaning some number of rows *before* the
offset or end of relation, or something like that...
The flip side of all this is that it's hard to get too excited about it. It's
just OFFSET / LIMIT. If it was a big deal we would have noticed years ago
anyways. It might not be worth the effort to change and introduce behaviour
changes for users at all.
Oh, and incidentally the problem with WARNING is that this is DML which could
potentially be executing hundreds or thousands of times per minute. A WARNING
is effectively an ERROR.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!
