Re: BUG #18929: After the view is created, executed query against the view definition, reported syntax error.

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: 707330139(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18929: After the view is created, executed query against the view definition, reported syntax error.
Date: 2025-05-19 15:52:50
Message-ID: c8706ea7-5a32-434b-bdc8-6cf8e2ad46c1@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 15/05/2025 17:41, Heikki Linnakangas wrote:
> On 15/05/2025 07:04, PG Bug reporting form wrote:
>> postgres=#  \d+ limit_thousand_v_3
>>                        View "public.limit_thousand_v_3"
>>    Column  |  Type   | Collation | Nullable | Default | Storage |
>> Description
>> ----------+---------+-----------+----------+---------+---------
>> +-------------
>>   thousand | integer |           |          |         | plain   |
>> View definition:
>>   SELECT thousand
>>     FROM onek
>>    WHERE thousand < 995
>>    ORDER BY thousand
>>   FETCH FIRST NULL::bigint + 1::bigint ROWS WITH TIES;
>> postgres=# SELECT thousand
>> postgres-#    FROM onek
>> postgres-#   WHERE thousand < 995
>> postgres-#   ORDER BY thousand
>> postgres-#  FETCH FIRST NULL::bigint + 1::bigint ROWS WITH TIES;
>> ERROR:  syntax error at or near "::"
>> LINE 5:  FETCH FIRST NULL::bigint + 1::bigint ROWS WITH TIES;
>>                           ^
>
> Agreed that's a bug. Attached is a simple patch to add parens to all
> deparsed FETCH FIRST n ROWS WITH TIES expressions.
>
> It would be nice to skip the parens for simple literals, but
> unfortunately it's non-trivial to distinguish Consts that are printed as
> simple literals from more complicated cases that are printed as
> typecasts, like '123'::bigint. XMLEXISTS is another expression type that
> takes a 'c_expr' in the the grammar, and it also just always adds the
> parens.
>
> I'll commit this fix, unless someone comes up with something more
> sophisticated.

Committed, thanks for the report.

--
Heikki Linnakangas
Neon (https://neon.tech)

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Nathan Bossart 2025-05-19 20:30:29 Re: BUG #18923: pg_dump 18beta1 fails to process complex table names
Previous Message Alena Rybakina 2025-05-19 15:47:05 Re: BUG #18935: The optimiser's choice of sort doubles the execution time.