| 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
| 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 |