the planner may try to generate them as a result of transitivity of the
existing int2-vs-int4 and int4-vs-int8 operators. In fact, it is now
necessary that mergejoinable cross-datatype operators form closed sets.
Add an opr_sanity regress test to detect missing operators.
FreeBSD/Intel and DecUX/Alpha machines. The bug appears in postgresql
6.5.3 and 7.0.2. Can someone please review it and apply it to the
source tree?
Sometimes when the postgres connection dies it is necessary to
attempt to reconnect. Calling the pgconnection::Connect method in a
derived class leaks memory because it does not clear the current
connection (if there is one). These patches ensures that any open
connections are closed before attempting to open a new one.
-Michael Richards
to use with a multiple-key index. Formerly we would only extract clauses
that had to do with the first key of the index, which was correct but
didn't exploit the index fully.
actually, but who could understand it with no comments? Fix bug
while at it: _bt_orderkeys would try to invoke comparisons on
NULL inputs, given the right sort of redundant quals.
mergejoinable qual clauses, and add them to the query quals. For
example, WHERE a = b AND b = c will cause us to add AND a = c.
This is necessary to ensure that it's safe to use these variables
as interchangeable sort keys, which is something 7.0 knows how to do.
Should provide a useful improvement in planning ability, too.
varlena elements work now. Allow assignment to previously-nonexistent
subscript position to extend array, but only for 1-D arrays and only
if adjacent to existing positions (could do more if we had a way to
represent nulls in arrays, but I don't want to tackle that now).
Arrange for assignment of NULL to an array element in UPDATE to be a
no-op, rather than setting the entire array to NULL as it used to.
(Throwing an error would be a reasonable alternative, but it's never
done that...) Update regress test accordingly.
work as expected. THe underlying implementation is essentially
'SET foo = array_set(foo, 1, bar)', so we have to turn the items
into nested invocations of array_set() to make it work correctly.
Side effect: we now complain about 'UPDATE tab SET foo = bar, foo = baz'
which is illegal per SQL92 but we didn't detect it before.
Remove a bunch of crufty code for large-object-based arrays, which is
superseded by TOAST and likely hasn't worked in a long time anyway.
Clean up array code a little, and in particular eliminate its habit
of scribbling on the input array (ie, modifying the input tuple :-().
