Re: BUG #19750: tsquery output omits parentheses, so the text reparses to a different value

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: kehan5800(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19750: tsquery output omits parentheses, so the text reparses to a different value
Date: 2026-10-05 18:24:35
Message-ID: 1090121.1791224675@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> tsquery's output function, infix() in src/backend/utils/adt/tsquery.c,
> parenthesises a binary operator's operand only when the operand's operator
> has lower priority than the parent (or, for <->, when it is the right
> operand). When the same operator, & or |, is nested on the right, no
> parentheses are written. The parser is left-associative, so that text
> reads back as a different tree, and tsquery equality compares trees:

On the whole I think this is intentional behavior, not a bug. The
only cases that don't "round trip" according to your definition are
"a & (b & c)" and "a | (b | c)", which are semantically equivalent
to the left-associative cases, so it seems like a legitimate
simplification to leave out the parens. The reason I think it was
intentional is that the code is actually more complex than it
would have to be otherwise: it treats OP_PHRASE differently from
the other binary operators, because for that the associativity
does matter.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message shihao zhong 2026-10-05 18:38:05 Re: BUG #17545: Incorrect selectivity for IS NOT DISTINCT FROM and NULLs
Previous Message Tom Lane 2026-10-05 17:39:06 Re: BUG #19742: `INTERSECT` under a `UNION ALL` with an empty arm fails with "could not find pathkey item t"