Re: Row pattern recognition

Hi Henson,

> Hi hackers,
>
> This refreshes the v48 series [1]: Jian He's review of the v47-000x
> cleanup patches [2] (my point-by-point reply [3]) is now applied as
> nocfbot-0069..0077. nocfbot-0001..0068 are unchanged from the last post
> [1] (rebase only), except nocfbot-0039, which is voided here (see below).
>
> Resolved since the last post:
>
> Jian He, round 5 -- the v47-0001..0004 patches plus the inline comments
> [2]. Applied across nocfbot-0069..0077 (issue map below).
>
> For Tatsuo -- two calls I'd like from you before this settles:

Ok, let me check...

> 1. nocfbot-0073 moves the DEFINE volatility rejection out of parse
> analysis into the planner, per the convention Jian and Tom noted. Two
> things to weigh: it is a small behavior change -- a volatile DEFINE
> hidden in a view is now rejected when the view is read, not at CREATE
> VIEW -- and the planner has no ParseState, so the error cursor is
> reconstructed from debug_query_string, a first at the optimizer stage.
> If either gives you pause, I'll rework it or split nocfbot-0073 out for
> separate review ahead of the cosmetic patches.

No pause from me.

> 2. LOWPRICE/UP/DOWN casing. I've left the variables upper-case (the
> standard and Oracle show them so), but EXPLAIN and deparse lower-case
> them today, so the examples and the actual output disagree. If you'd
> prefer the section lower-cased, I'll do it as a doc patch.

I see no problem here. PostgreSQL always convert identifiers into
lower case. Evenrybody knows that.

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