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
