Re: Row pattern recognition

From: Henson Choi <assam258(at)gmail(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: vik(at)postgresfriends(dot)org, er(at)xs4all(dot)nl, jacob(dot)champion(at)enterprisedb(dot)com, david(dot)g(dot)johnston(at)gmail(dot)com, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Row pattern recognition
Date: 2026-02-27 05:44:01
Message-ID: CAAAe_zDaXmj9usEBFdMUvBR8Rtr4WsYW5x-CEh7B+uc0jRukuA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tatsuo,

The standard does not allow to use range variables, declared in the
> FROM clause, in the DEFINE clause (19075-5 6.5). Attached patch raises
> an error in this case.
>

Agreed. §6.5 is explicit about mutual exclusivity of the two sets of
range variables. Your patch is correct for this case.

Also, currently we do not support pattern variable range vars in the
> DEFINE caluse (e.g. UP.price). If used, we see a confusing error
> message:
>
> ERROR: missing FROM-clause entry for table "UP"
> LINE 13: UP AS UP.price > PREV(price),
> ^
>

Pattern variable qualified names like `UP.price` are actually valid
standard syntax (§4.16 uses them in examples), so "is not allowed"
is misleading — "is not supported" would be more accurate.

To distinguish the two cases, we could expose `patternVarNames` via
ParseState (it is already collected by `validateRPRPatternVarCount`
before DEFINE expressions are transformed) and check in
`transformColumnRef` whether the qualifier is a pattern variable:

- pattern variable qualifier → "not supported"
- anything else → "not allowed"

Would it be okay if I revise the patch along those lines?

Best regards,
Henson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2026-02-27 05:55:39 Re: Row pattern recognition
Previous Message Amit Kapila 2026-02-27 05:33:33 Re: Skipping schema changes in publication