Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
От | Japin Li |
---|---|
Тема | Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption |
Дата | |
Msg-id | ME3P282MB316607C153D423024BC5645CB6ED2@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-bugs |
On Thu, 16 May 2024 at 23:27, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > On 2024-May-16, Japin Li wrote: > >> I find that the FETCH FIRST ... ROWS WITH TIES does not support type casting. >> For example: >> >> postgres=# SELECT * FROM pg_class ORDER BY relname FETCH FIRST 2::bigint ROWS WITH TIES; >> ERROR: syntax error at or near "::" >> LINE 1: ...ECT * FROM pg_class ORDER BY relname FETCH FIRST 2::bigint R... >> ^ > > Why do you need this? The standard says > The limitCount is stored as bigint and deparseConst() will automatically append '::bigint'. So I do the typecast. > <fetch first clause> ::= FETCH { FIRST | NEXT } [ <fetch first quantity> ] { ROW | ROWS } { ONLY | WITH TIES } > <fetch first quantity> ::= <fetch first row count> | <fetch first percentage> > <offset row count> ::= <simple value specification> > <fetch first row count> ::= <simple value specification> > > which doesn't seem to leave room for a cast. > > I didn't try super extensively, but this works: > select 1 from pg_class fetch first 281474976710656 rows only; > so the count is already not restricted to be an int32 value. Since it is of type int, why should it be stored as bigint? -- Regards, Japin Li
В списке pgsql-bugs по дате отправления: