pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedincorrect syntax for offset
8+ messages / 5 participants
[nested] [flat]
Commits from this thread:
2020-10-05 9cc3d614a9 019eb962fb Doc: fix parameter names in the docs of a couple of functions.
* incorrect syntax for offset
@ 2009-08-18 22:08 Jaime Casanova <jcasanov@systemguards.com.ec>
0 siblings, 2 replies; 8+ messages in thread
From: Jaime Casanova @ 2009-08-18 22:08 UTC (permalink / raw)
To: pgsql-docs
Hi.
Our current docs says that we support the following syntax (i'm
putting just the lines that disturbes me) inside a SELECT statement
"""
[ LIMIT { count | ALL } ]
[ OFFSET start [ ROW | ROWS ] ]
[ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
"""
i read that as allow me to use the ROWS in an OFFSET clause whatever i
use LIMIT or FETCH for limiting results but seems like we try hard to
make a distinguish from old syntax and new (sql standard) syntax
pruebas=# select * from tab1 limit 3 offset 2 rows;
ERROR: syntax error at or near "rows"
LINE 1: select * from tab1 limit 3 offset 2 rows;
^
pruebas=# select * from tab1 offset 2 fetch next 3 rows only;
ERROR: syntax error at or near "fetch"
LINE 1: select * from tab1 offset 2 fetch next 3 rows only;
^
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: incorrect syntax for offset
@ 2009-08-18 22:56 Tom Lane <tgl@sss.pgh.pa.us>
parent: Jaime Casanova <jcasanov@systemguards.com.ec>
1 sibling, 0 replies; 8+ messages in thread
From: Tom Lane @ 2009-08-18 22:56 UTC (permalink / raw)
To: Jaime Casanova <jcasanov@systemguards.com.ec>; +Cc: pgsql-docs
Jaime Casanova <jcasanov@systemguards.com.ec> writes:
> i read that as allow me to use the ROWS in an OFFSET clause whatever i
> use LIMIT or FETCH for limiting results but seems like we try hard to
> make a distinguish from old syntax and new (sql standard) syntax
> pruebas=# select * from tab1 limit 3 offset 2 rows;
> ERROR: syntax error at or near "rows"
> LINE 1: select * from tab1 limit 3 offset 2 rows;
> ^
> pruebas=# select * from tab1 offset 2 fetch next 3 rows only;
> ERROR: syntax error at or near "fetch"
> LINE 1: select * from tab1 offset 2 fetch next 3 rows only;
Hmm. Seems like we could refactor the select_limit production so it
actually allows all the reasonable combinations. Let me have a look...
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: incorrect syntax for offset
@ 2010-02-23 22:47 Bruce Momjian <bruce@momjian.us>
parent: Jaime Casanova <jcasanov@systemguards.com.ec>
1 sibling, 0 replies; 8+ messages in thread
From: Bruce Momjian @ 2010-02-23 22:47 UTC (permalink / raw)
To: Jaime Casanova <jcasanov@systemguards.com.ec>; +Cc: pgsql-docs
Jaime Casanova wrote:
> Hi.
>
> Our current docs says that we support the following syntax (i'm
> putting just the lines that disturbes me) inside a SELECT statement
> """
> [ LIMIT { count | ALL } ]
> [ OFFSET start [ ROW | ROWS ] ]
> [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
> """
>
> i read that as allow me to use the ROWS in an OFFSET clause whatever i
> use LIMIT or FETCH for limiting results but seems like we try hard to
> make a distinguish from old syntax and new (sql standard) syntax
>
> pruebas=# select * from tab1 limit 3 offset 2 rows;
> ERROR: syntax error at or near "rows"
> LINE 1: select * from tab1 limit 3 offset 2 rows;
> ^
> pruebas=# select * from tab1 offset 2 fetch next 3 rows only;
> ERROR: syntax error at or near "fetch"
> LINE 1: select * from tab1 offset 2 fetch next 3 rows only;
FYI, this is fixed in 9.0:
test=> select * from tab1 limit 3 offset 2 rows;
x
---
(0 rows)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 8+ messages in thread
* Wrong parameter names for make_interval (Postgres 13)
@ 2020-10-05 13:56 Thomas Kellerer <shammat@gmx.net>
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Kellerer @ 2020-10-05 13:56 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org
There is a typo in the parameter names of the make_interval() function.
The parameter names are all defined with plural, not singular as it is shown
in the Postgres 13 manual.
So instead of
make_interval ( [ year int [, month int [, week int [, day int [, hour int [, min int [, sec double precision ]]]]]]] )
it should be
make_interval ( [ years int [, months int [, weeks int [, days int [,hours int [, mins int [, secs double precision ]]]]]]] )
Thomas
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Wrong parameter names for make_interval (Postgres 13)
@ 2020-10-05 14:33 Pavel Stehule <pavel.stehule@gmail.com>
parent: Thomas Kellerer <shammat@gmx.net>
0 siblings, 1 reply; 8+ messages in thread
From: Pavel Stehule @ 2020-10-05 14:33 UTC (permalink / raw)
To: Pg Docs <pgsql-docs@lists.postgresql.org>
po 5. 10. 2020 v 15:56 odesílatel Thomas Kellerer <shammat@gmx.net> napsal:
> There is a typo in the parameter names of the make_interval() function.
>
> The parameter names are all defined with plural, not singular as it is
> shown
> in the Postgres 13 manual.
>
> So instead of
>
> make_interval ( [ year int [, month int [, week int [, day int [, hour
> int [, min int [, sec double precision ]]]]]]] )
>
> it should be
>
> make_interval ( [ years int [, months int [, weeks int [, days int
> [,hours int [, mins int [, secs double precision ]]]]]]] )
>
this syntax is not correct too
It should be
make_interval( years int default 0, month int default 0, days int
default 0, hours int default 0, secs double precision default 0)
Regards
Pavel
> Thomas
>
>
>
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Wrong parameter names for make_interval (Postgres 13)
@ 2020-10-05 15:53 Tom Lane <tgl@sss.pgh.pa.us>
parent: Pavel Stehule <pavel.stehule@gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Tom Lane @ 2020-10-05 15:53 UTC (permalink / raw)
To: Pavel Stehule <pavel.stehule@gmail.com>; +Cc: Thomas Kellerer <shammat@gmx.net>; Pg Docs <pgsql-docs@lists.postgresql.org>
Pavel Stehule <pavel.stehule@gmail.com> writes:
> po 5. 10. 2020 v 15:56 odesílatel Thomas Kellerer <shammat@gmx.net> napsal:
>> So instead of
>> make_interval ( [ year int [, month int [, week int [, day int [, hour
>> int [, min int [, sec double precision ]]]]]]] )
>> it should be
>> make_interval ( [ years int [, months int [, weeks int [, days int
>> [,hours int [, mins int [, secs double precision ]]]]]]] )
Right, fixed.
> this syntax is not correct too
> It should be
> make_interval( years int default 0, month int default 0, days int
> default 0, hours int default 0, secs double precision default 0)
IIRC, I intentionally changed that in v13; the existence of the defaults
is sufficiently covered by the text "... fields, each of which can default
to zero". I think that was partly motivated by trying to get the function
signature to fit into limited space. The final docs-table design we ended
up with might allow undoing it, but I don't see any real reason to. The
other way is more verbose and not any clearer.
I spent a little bit of time scanning for other discrepancies between
func.sgml and pg_proc.proargnames, and found several, mostly though
not exclusively in the JSON functions. In these other cases, though,
I think there might be a good argument for making pg_proc fit the docs
not the other way around. In the JSON functions, for example, pg_proc
randomly has some functions calling the main JSON[B] input "target"
while others call it "from_json" or "json_in". I'm not real sure
which of those names is preferable, but inconsistency is not preferable.
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Wrong parameter names for make_interval (Postgres 13)
@ 2020-10-05 16:48 Pavel Stehule <pavel.stehule@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 8+ messages in thread
From: Pavel Stehule @ 2020-10-05 16:48 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thomas Kellerer <shammat@gmx.net>; Pg Docs <pgsql-docs@lists.postgresql.org>
po 5. 10. 2020 v 17:53 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
> > po 5. 10. 2020 v 15:56 odesílatel Thomas Kellerer <shammat@gmx.net>
> napsal:
> >> So instead of
> >> make_interval ( [ year int [, month int [, week int [, day int [, hour
> >> int [, min int [, sec double precision ]]]]]]] )
> >> it should be
> >> make_interval ( [ years int [, months int [, weeks int [, days int
> >> [,hours int [, mins int [, secs double precision ]]]]]]] )
>
> Right, fixed.
>
> > this syntax is not correct too
> > It should be
> > make_interval( years int default 0, month int default 0, days int
> > default 0, hours int default 0, secs double precision default 0)
>
> IIRC, I intentionally changed that in v13; the existence of the defaults
> is sufficiently covered by the text "... fields, each of which can default
> to zero". I think that was partly motivated by trying to get the function
> signature to fit into limited space. The final docs-table design we ended
> up with might allow undoing it, but I don't see any real reason to. The
> other way is more verbose and not any clearer.
>
I don't understand,
the syntax [ a [, b]] means
so a and b are optional, but b can be used only when a is used. But for
make_interval I can use "months" arguments without specification of "years"
argument.
I don't know the correct BNF for arguments with default values, but using
this doesn't look correct.
Regards
Pavel
> I spent a little bit of time scanning for other discrepancies between
> func.sgml and pg_proc.proargnames, and found several, mostly though
> not exclusively in the JSON functions. In these other cases, though,
> I think there might be a good argument for making pg_proc fit the docs
> not the other way around. In the JSON functions, for example, pg_proc
> randomly has some functions calling the main JSON[B] input "target"
> while others call it "from_json" or "json_in". I'm not real sure
> which of those names is preferable, but inconsistency is not preferable.
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Wrong parameter names for make_interval (Postgres 13)
@ 2020-10-05 16:56 Pavel Stehule <pavel.stehule@gmail.com>
parent: Pavel Stehule <pavel.stehule@gmail.com>
0 siblings, 0 replies; 8+ messages in thread
From: Pavel Stehule @ 2020-10-05 16:56 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thomas Kellerer <shammat@gmx.net>; Pg Docs <pgsql-docs@lists.postgresql.org>
po 5. 10. 2020 v 18:48 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
napsal:
>
>
> po 5. 10. 2020 v 17:53 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>
>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> > po 5. 10. 2020 v 15:56 odesílatel Thomas Kellerer <shammat@gmx.net>
>> napsal:
>> >> So instead of
>> >> make_interval ( [ year int [, month int [, week int [, day int [, hour
>> >> int [, min int [, sec double precision ]]]]]]] )
>> >> it should be
>> >> make_interval ( [ years int [, months int [, weeks int [, days int
>> >> [,hours int [, mins int [, secs double precision ]]]]]]] )
>>
>> Right, fixed.
>>
>> > this syntax is not correct too
>> > It should be
>> > make_interval( years int default 0, month int default 0, days int
>> > default 0, hours int default 0, secs double precision default 0)
>>
>> IIRC, I intentionally changed that in v13; the existence of the defaults
>> is sufficiently covered by the text "... fields, each of which can default
>> to zero". I think that was partly motivated by trying to get the function
>> signature to fit into limited space. The final docs-table design we ended
>> up with might allow undoing it, but I don't see any real reason to. The
>> other way is more verbose and not any clearer.
>>
>
> I don't understand,
>
> the syntax [ a [, b]] means
>
> so a and b are optional, but b can be used only when a is used. But for
> make_interval I can use "months" arguments without specification of "years"
> argument.
>
> I don't know the correct BNF for arguments with default values, but using
> this doesn't look correct.
>
I forgot the behavior of positional arguments. So this syntax is correct.
I am sorry for the noise.
Regards
Pavel
> Regards
>
> Pavel
>
>
>
>> I spent a little bit of time scanning for other discrepancies between
>> func.sgml and pg_proc.proargnames, and found several, mostly though
>> not exclusively in the JSON functions. In these other cases, though,
>> I think there might be a good argument for making pg_proc fit the docs
>> not the other way around. In the JSON functions, for example, pg_proc
>> randomly has some functions calling the main JSON[B] input "target"
>> while others call it "from_json" or "json_in". I'm not real sure
>> which of those names is preferable, but inconsistency is not preferable.
>>
>> regards, tom lane
>>
>
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2020-10-05 16:56 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-08-18 22:08 incorrect syntax for offset Jaime Casanova <jcasanov@systemguards.com.ec>
2009-08-18 22:56 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-02-23 22:47 ` Bruce Momjian <bruce@momjian.us>
2020-10-05 13:56 Wrong parameter names for make_interval (Postgres 13) Thomas Kellerer <shammat@gmx.net>
2020-10-05 14:33 ` Re: Wrong parameter names for make_interval (Postgres 13) Pavel Stehule <pavel.stehule@gmail.com>
2020-10-05 15:53 ` Re: Wrong parameter names for make_interval (Postgres 13) Tom Lane <tgl@sss.pgh.pa.us>
2020-10-05 16:48 ` Re: Wrong parameter names for make_interval (Postgres 13) Pavel Stehule <pavel.stehule@gmail.com>
2020-10-05 16:56 ` Re: Wrong parameter names for make_interval (Postgres 13) Pavel Stehule <pavel.stehule@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox