Tom Lane [Fri, 16 Jul 1999 23:09:45 +0000 (23:09 +0000)]
Add back improperly removed #include for config.h.
This probably ought to be kept in *all* the port files, but these two
are the only ones that generated compiler warnings for me ...
Tom Lane [Fri, 16 Jul 1999 22:29:42 +0000 (22:29 +0000)]
Allow bare column names to be subscripted as arrays. This
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.
Tom Lane [Fri, 16 Jul 1999 22:17:06 +0000 (22:17 +0000)]
Revise _bt_binsrch() so that its binary search loop takes
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.
Tom Lane [Sun, 11 Jul 1999 02:04:19 +0000 (02:04 +0000)]
Ignore resjunk targetlist entries when matching arguments to
a SubLink with the subplan's targetlist. This fixes a problem seen with,
for example, a subselect that uses GROUP BY.
Tom Lane [Sat, 10 Jul 1999 18:21:59 +0000 (18:21 +0000)]
Fix tuplecmp() to ensure repeatable sort ordering of tuples
that contain null fields. Old code would produce erratic sort results
because comparisons of tuples containing nulls could produce inconsistent
answers.
Bruce Momjian [Thu, 8 Jul 1999 03:32:57 +0000 (03:32 +0000)]
Test Case:
----------
exec sql begin declare section;
short s ;
unsigned short us;
exec sql end declare section;
exec sql create table test(s smallint, us smallint);
exec sql commit;
s = 1; us =32000;
exec sql insert into test values( :s, :us ) ; <== error
Bruce Momjian [Thu, 8 Jul 1999 03:22:46 +0000 (03:22 +0000)]
> In both datetime_trunc() and timespan_trunc() in dt.c,
> 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?
Bruce Momjian [Thu, 8 Jul 1999 00:27:01 +0000 (00:27 +0000)]
pg_atoi() does range check on int4 data only if
"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.)