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