Make plpgsql complain about conflicting IN and OUT parameter names.
The core CREATE FUNCTION code only enforces that IN parameter names are
non-duplicate, and that OUT parameter names are separately non-duplicate.
This is because some function languages might not have any confusion
between the two
Fix integer overflow in text_format function, reported by Dean Rasheed.
In the passing, clarify the comment on why text_format_nv wrapper is needed.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/34be83b7e142a718c7a831c9df9763aa83fe4cd5
Modified Files
-
Improve hash_array() logic for combining hash values.
The new logic is less vulnerable to transpositions.
This invalidates the contents of hash indexes built with the old
functions; hence, bump catversion.
Dean Rasheed
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdif
Lobotomize typmod check in convert_tuples_by_position, back branches only.
convert_tuples_by_position was rejecting attempts to coerce a record field
with -1 typmod to the same type with a non-default typmod. This is in fact
the "correct" thing to do (since we're just going to do a type relabelin
Lobotomize typmod check in convert_tuples_by_position, back branches only.
convert_tuples_by_position was rejecting attempts to coerce a record field
with -1 typmod to the same type with a non-default typmod. This is in fact
the "correct" thing to do (since we're just going to do a type relabelin
Message style improvements
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/c58b945e23e63a0baca67b216a5225b34de84cce
Modified Files
--
src/bin/pg_dump/pg_dumpall.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Sent via pgsql-committers m
Replace strdup() with pstrdup(), to avoid leaking memory.
It's been like this since the seg module was introduced, so backpatch to
8.2 which is the oldest supported version.
Branch
--
REL9_0_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/7541d32e86b739afb41e711a4c790aed446dd0
Install defenses against overflow in BuildTupleHashTable().
The planner can sometimes compute very large values for numGroups, and in
cases where we have no alternative to building a hashtable, such a value
will get fed directly to BuildTupleHashTable as its nbuckets parameter.
There were two ways
Install defenses against overflow in BuildTupleHashTable().
The planner can sometimes compute very large values for numGroups, and in
cases where we have no alternative to building a hashtable, such a value
will get fed directly to BuildTupleHashTable as its nbuckets parameter.
There were two ways
Install defenses against overflow in BuildTupleHashTable().
The planner can sometimes compute very large values for numGroups, and in
cases where we have no alternative to building a hashtable, such a value
will get fed directly to BuildTupleHashTable as its nbuckets parameter.
There were two ways
Install defenses against overflow in BuildTupleHashTable().
The planner can sometimes compute very large values for numGroups, and in
cases where we have no alternative to building a hashtable, such a value
will get fed directly to BuildTupleHashTable as its nbuckets parameter.
There were two ways
Install defenses against overflow in BuildTupleHashTable().
The planner can sometimes compute very large values for numGroups, and in
cases where we have no alternative to building a hashtable, such a value
will get fed directly to BuildTupleHashTable as its nbuckets parameter.
There were two ways
On 22.05.2011 21:18, Tom Lane wrote:
Heikki Linnakangas writes:
Pull up isReset flag from AllocSetContext to MemoryContext struct. This
avoids the overhead of one function call when calling MemoryContextReset(),
and it seems like the isReset optimization would be applicable to any new
memory co
13 matches
Mail list logo
