Re: Row pattern recognition

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.

> /* arity: a value expression and an optional offset */
> Typo: arity

"arity" may be an unfamiliar term, so I'll reword the comment in plainer
language ("takes a value expression and an optional offset").

> Simplify ParseFuncOrColumn:
> It now routes to ParseRPRNavCall exclusively when ParseExprKind is
> EXPR_KIND_RPR_DEFINE and not column projection and list_length(funcname)
> == 1. Original behavior is preserved otherwise.
> Centralize error handling:
> Treat RPR navigation as FUNCDETAIL_NORMAL to reuse the common error
> handling in ParseFuncOrColumn, effectively stripping redundant error
> checks from ParseRPRNavCall.

I'd take this structural part -- it's a clear cleanup: ParseRPRNavCall
drops the duplicated decoration checks while the common path gives the
identical messages, with no change in behavior or output.

Two user-visible changes in the patch I'd rather settle on their own
before taking them:

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?

2. The offset type-mismatch message.

   The patch rephrases

     offset argument of %s must be type bigint, not type %s
   to
     %s offset argument of type %s cannot be coerced to the expected
     bigint   (+ a hint)

   The behavior is identical, so I'd keep the original wording.  "argument
   ... must be type X, not type Y" is the established phrasing -- it's what
   coerce_to_boolean() produces, and the non-boolean DEFINE error in this
   same feature already uses it.  Rewording only the offset message would
   be inconsistent with that, for no behavioral gain.

One small process note: for patches that aren't really being proposed to
the list yet -- ones still under review, or throwaway implementations
written just to analyze a problem -- could you send them off-list or as a
pull request instead?  That keeps the thread focused on what's actually
being proposed for the patch.

Best regards,
Henson