creates a reduce/reduce conflict, which I resolved by changing the
'AexprConst -> Typename Sconst' rule to 'AexprConst -> SimpleTypename Sconst'.
In other words, a subscripted type declaration can't be used in that
syntax any longer. This seems a small price to pay for not having to
qualify subscripted columns anymore.
Other cleanups: rename res_target_list to update_target_list, and remove
productions for variants that are not legal in an UPDATE target list;
rename res_target_list2 to plain target_list; delete position_expr
in favor of using b_expr in that production; merge opt_indirection
into attr nonterminal, since there are no places where an unsubscripted
attr is wanted; fix typos in Param support; change case_arg so that
an arbitrary a_expr is allowed, not only a column name.
care of equal-key cases, eliminating bt_firsteq(). The linear search
formerly done by bt_firsteq() took a lot of time in the case where many
equal keys appear on the same page.
that contain null fields. Old code would produce erratic sort results
because comparisons of tuples containing nulls could produce inconsistent
answers.
> the DTK_MICROSEC case is just like the DTK_MILLISEC case.
> I think this is wrong and it ought to look like
> fsec = rint(fsec * 1000000) / 1000000;
> no?
Tom Lane.
"HAS_LONG_LONG" is defined based on the assumption that
strtol() would return ERANGE if a platform does not support
64-bit integers. In current PostgreSQL 6.5 (and 6.4.2)
distribution, "HAS_LONG_LONG" is defined only if platform
is "alpha". (See include/port/alpha.h) I think the int4
range check should apply to linux_alpha as well. (I have
not tested yet but I guess this might be applicable to
newer Linux/i386 distributions which includes new GCC which
implements long int as 64-bit int.)
