LIMIT NULL

David E. Wheeler wrote:

Howdy,

Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
so, I'd like to submit a patch to document it, because I've found it
useful in SQL functions:

http://justatheory.com/computers/databases/postgresql/dynamic-limit.html

Uh, I figure LIMIT NULL should return no rows.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Mon, Feb 2, 2009 at 12:58 PM, Bruce Momjian <bruce@momjian.us> wrote:

David E. Wheeler wrote:

Howdy,

Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
so, I'd like to submit a patch to document it, because I've found it
useful in SQL functions:

http://justatheory.com/computers/databases/postgresql/dynamic-limit.html

Uh, I figure LIMIT NULL should return no rows.

Wouldn't that be LIMIT 0? Per SQL spec, doesn't NULL refer to an
unknown quantity? Making it mean ALL seems more useful than making it
mean 0, since you can already write 0 if you want 0.

...Robert

On Feb 2, 2009, at 9:58 AM, Bruce Momjian wrote:

Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
so, I'd like to submit a patch to document it, because I've found it
useful in SQL functions:

http://justatheory.com/computers/databases/postgresql/dynamic-limit.html

Uh, I figure LIMIT NULL should return no rows.

Well, LIMIT 0 does that, and it's useful to have a type-compatible
option to LIMIT that allows it to return all rows. And I say type-
compatible, because you can't pass "ALL" as a bare string via a
function like COALESCE.

Best,

David

Bruce Momjian <bruce@momjian.us> wrote:

David E. Wheeler wrote:

Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`?

Uh, I figure LIMIT NULL should return no rows.

Why? Since the normal meaning of NULL is "value unknown or does not
apply" it would seem to be most reasonable, if it's going to be
accepted in a LIMIT clause, to have it mean "the LIMIT does not
apply".

Plus, if it has been accepted with the "no limit" semantics, wouldn't
it require a really good reason to break backwards compatibility?

-Kevin

Bruce Momjian <bruce@momjian.us> writes:

Uh, I figure LIMIT NULL should return no rows.

It's worked the way it does now since 7.1, and no one has complained;
in fact we've gotten bug reports when it was broken by the int8-limit
patch. So there are people depending on the behavior.

regards, tom lane

On Feb 2, 2009, at 10:17 AM, Tom Lane wrote:

It's worked the way it does now since 7.1, and no one has complained;
in fact we've gotten bug reports when it was broken by the int8-limit
patch. So there are people depending on the behavior.

Yeah, it's very useful. Here's a patch for the docs about it.

Thanks,

David

"David E. Wheeler" <david@kineticode.com> writes:

On Feb 2, 2009, at 10:17 AM, Tom Lane wrote:

It's worked the way it does now since 7.1, and no one has complained;
in fact we've gotten bug reports when it was broken by the int8-limit
patch. So there are people depending on the behavior.

Yeah, it's very useful. Here's a patch for the docs about it.

Seems to me that the SELECT reference page is a more appropriate place
for this type of detail. I've applied a patch there.

regards, tom lane

On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:

Yeah, it's very useful. Here's a patch for the docs about it.

Seems to me that the SELECT reference page is a more appropriate place
for this type of detail. I've applied a patch there.

What about both? The LIMIT page is the first page I'd look for it, and
the ALL note is there…

Thanks,

David

"David E. Wheeler" <david@kineticode.com> writes:

On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:

Seems to me that the SELECT reference page is a more appropriate place
for this type of detail. I've applied a patch there.

What about both?

We don't really have space to document every little niggling detail in
two places; if we did that, the main docs would become unreadably dense.

(I think it's justifiable to regard this as a "niggling detail" because
no one's asked about it before.)

regards, tom lane

On Feb 2, 2009, at 1:10 PM, Tom Lane wrote:

"David E. Wheeler" <david@kineticode.com> writes:

On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:

Seems to me that the SELECT reference page is a more appropriate
place
for this type of detail. I've applied a patch there.

What about both?

We don't really have space to document every little niggling detail in
two places; if we did that, the main docs would become unreadably
dense.

What, disk space? What do you mean by “space”?

(I think it's justifiable to regard this as a "niggling detail"
because
no one's asked about it before.)

Sure.

Best,

David

We don't really have space to document every little niggling detail in
two places; if we did that, the main docs would become unreadably dense.

What, disk space? What do you mean by "space"?

Brain space.

...Robert

On Feb 2, 2009, at 1:52 PM, Robert Haas wrote:

We don't really have space to document every little niggling
detail in
two places; if we did that, the main docs would become unreadably
dense.

What, disk space? What do you mean by "space"?

Brain space.

Heh. Okay. Well, should there be a separate LIMIT/OFFSET documentation
page? Why have this stuff in two places? I had assumed that the LIMIT/
OFFSET page would have all the specifies on these clauses, and that
the SELECT page (which is kind of overwhelming as it is) would refer
to it…

Thanks,

David

David E. Wheeler wrote:

Heh. Okay. Well, should there be a separate LIMIT/OFFSET documentation
page? Why have this stuff in two places? I had assumed that the
LIMIT/OFFSET page would have all the specifies on these clauses, and
that the SELECT page (which is kind of overwhelming as it is) would
refer to it�

We have one page per main SQL verb (e.g. SELECT or CREATE TABLE). I
don't think we want to break it up more than that. One page for each
clause would be a nightmare to maintain.

cheers

andrew

On Feb 3, 2009, at 8:40 AM, Andrew Dunstan wrote:

We have one page per main SQL verb (e.g. SELECT or CREATE TABLE). I
don't think we want to break it up more than that. One page for each
clause would be a nightmare to maintain.

Then should the LIMIT/OFFSET page go away?

Best,

David

On Tuesday 03 February 2009 10:42:30 am David E. Wheeler wrote:

On Feb 3, 2009, at 8:40 AM, Andrew Dunstan wrote:

We have one page per main SQL verb (e.g. SELECT or CREATE TABLE). I
don't think we want to break it up more than that. One page for each
clause would be a nightmare to maintain.

Then should the LIMIT/OFFSET page go away?

Best,

David

I agree that it's confusing when one piece of LIMIT documentation is not with
the rest.

If looking for information about limits, I would go here:
http://www.postgresql.org/docs/8.3/static/queries-limit.html
and consider it to be an authoritative source.
If somebody told me something about LIMIT that was not on that page, I'd say
to them to go back and double check the docs...

Rick Vernam <rickv@hobi.com> writes:

If looking for information about limits, I would go here:
http://www.postgresql.org/docs/8.3/static/queries-limit.html
and consider it to be an authoritative source.

The reference documentation is *always* intended to be more complete and
more authoritative than the narrative description. If you don't think
so then you need to readjust your expectations.

regards, tom lane

David E. Wheeler wrote:

On Feb 3, 2009, at 8:40 AM, Andrew Dunstan wrote:

We have one page per main SQL verb (e.g. SELECT or CREATE TABLE). I
don't think we want to break it up more than that. One page for each
clause would be a nightmare to maintain.

Then should the LIMIT/OFFSET page go away?

I was referring to the reference section. I see you were referring to
the more descriptive but probably less complete Section II.

I see Section II says at the beginning: "Readers looking for a complete
description of a particular command should look into Part VI
<http://www.postgresql.org/docs/current/static/reference.html&gt;.&quot;.

cheers

andrew

On Tuesday 03 February 2009 3:06:27 pm Tom Lane wrote:

Rick Vernam <rickv@hobi.com> writes:

If looking for information about limits, I would go here:
http://www.postgresql.org/docs/8.3/static/queries-limit.html
and consider it to be an authoritative source.

The reference documentation is *always* intended to be more complete and
more authoritative than the narrative description. If you don't think
so then you need to readjust your expectations.

regards, tom lane

very well, I did not know that.
expectations readjusted. thanks.

On Feb 3, 2009, at 1:30 PM, Andrew Dunstan wrote:

I was referring to the reference section. I see you were referring
to the more descriptive but probably less complete Section II.

Yes.

I see Section II says at the beginning: "Readers looking for a
complete description of a particular command should look into Part
VI <http://www.postgresql.org/docs/current/static/reference.html&gt;.&quot;.

Yes, but not on the page for the command, FWIW, which one often
reaches by doing a search on "LIMIT". Finding that page via search, I
would assume that it was comprehensive.

The division between what's documented in section II and what's in
section VI seems a but fuzzy, neh?

Best,

David