Re: Negative LIMIT and OFFSET?
От | Jonah H. Harris |
---|---|
Тема | Re: Negative LIMIT and OFFSET? |
Дата | |
Msg-id | 36e682920712131917x7038a822paaa085103afc9b0b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Negative LIMIT and OFFSET? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Negative LIMIT and OFFSET?
|
Список | pgsql-hackers |
On Dec 13, 2007 10:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I guess that on purely philosophical grounds, it's not an unreasonable > behavior. For example, "LIMIT n" means "output at most n tuples", > not "output exactly n tuples". So when it outputs no tuples in the face > of a negative limit, it's meeting its spec. If you want to throw an > error for negative limit, shouldn't you logically also throw an error > for limit larger than the actual number of rows produced by the subplan? Hmm, good point. It does seem like if you're going to be pedantic, you should be pedantic on both counts. Though, I could understand throwing an error on a negative, because that's likely a bug in the user's code and would enable them to find out what's wrong. On the limit-larger-than-tuples-returned case, I don't think it should throw an error because it's generally considered as, "at most this many". I don't see a case where any user would think that a negative limit *should* be allowed. 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. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com Edison, NJ 08837 | http://www.enterprisedb.com/
В списке pgsql-hackers по дате отправления: