public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tatsuo Ishii <[email protected]>
To: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: Row pattern recognition
Date: Thu, 18 Jun 2026 18:50:07 +0900 (JST)
Message-ID: <[email protected]> (raw)
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>
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
view thread (130+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Row pattern recognition
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox