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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
Следующее
От: Japin Li
Дата:
Сообщение: Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption