Date: Thu, 18 Jun 2026 18:50:07 +0900 (JST)
Message-Id: <20260618.185007.1430819167281911424.ishii@postgresql.org>
To: assam258@gmail.com
Cc: jian.universality@gmail.com, zsolt.parragi@percona.com,
 sjjang112233@gmail.com, vik@postgresfriends.org, er@xs4all.nl,
 jacob.champion@enterprisedb.com, david.g.johnston@gmail.com,
 peter@eisentraut.org, li.evan.chao@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: Row pattern recognition
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: 
 <CAAAe_zDfrGSTqhgy8vOC1K6mzDsqVJGEmMy5N84G6=5EJT6--g@mail.gmail.com>
References: 
 <CACJufxFAQhbOD9EVCTAy-VwDbG4446N10GsxCcgdpFnjHO1Efw@mail.gmail.com>
	<CACJufxG6rKfd0WtsVZgzcoh8vOEwo_8UDWkuOd888ATavNv_uw@mail.gmail.com>
	<CAAAe_zDfrGSTqhgy8vOC1K6mzDsqVJGEmMy5N84G6=5EJT6--g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260618.185007.1430819167281911424.ishii%40postgresql.org>
Precedence: bulk

Hi Henson,

> Hi Jian and Tatsuo,
> 
> Thanks for the patch and the careful review.
> 
> Tatsuo, item 1 below (attribute notation inside a DEFINE clause) is a
> question for you; the rest is feedback on Jian's patch.

> 1. Attribute notation inside a DEFINE clause, e.g. (f).prev.
> 
>    The guard this change removes is one I deliberately left undecided
>    during development (hence the XXX comment), so I'd keep it for now and
>    ask here.  Without it, (f).prev with no such field gives a generic
>    "column \"prev\" not found ..." instead of the dedicated "cannot use
>    row pattern navigation function PREV in attribute notation".  Three
>    options:
> 
>    (a) Treat (f).prev as an ordinary function (prev(f)), the same as
>        outside a DEFINE clause -- which is what the patch does.
> 
>    (b) Treat (f).prev as the navigation function -- read the attribute
>        notation as navigation.  An ordinary function of that name is still
>        reachable as public.prev(...).
> 
>    (c) Reject the ambiguous (f).prev with a dedicated error (what is
>        currently committed), rather than resolving it one way or the
>        other.
> 
>    My own leaning is actually (a) -- it keeps attribute notation behaving
>    the same inside and outside a DEFINE clause.  (c) is what's in the tree
>    now, and either way it changes the user-visible error and SQLSTATE, so
>    I'd rather settle this explicitly than let the refactor decide it
>    silently.  Tatsuo, what do you think?

I think either (a) or (c) is fine. (b) gives no clear benefit to
users. Who want to write (f).prev? Also (f, 10).prev is a syntax
error, which confuses users.  If choosing (a) makes our code cleaner
and more logical, I have no reason to against it.

Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp