Mahmoud Taghizadeh

> * Consider sorting hash buckets so entries can be found using a binary
>   search, rather than a linear scan
> * In hash indexes, consider storing the hash value with or instead
>   of the key itself

> * Add the features of packages
> 	o  Make private objects accessable only to objects in the same schema
> 	o  Allow current_schema.objname to access current schema objects
> 	o  Add session variables
> 	o  Allow nested schemas

consistency and to prevent rounding for days < 30.  Also round off all
trailing zeros, rather than leaving an even number of digits.

per report from Boris van Schooten.

Marko Kreen

used. From Jaime Casanova.

and modes to be included when naming an existing function.

Display only 9 not 10 digits of precision for timestamp values when
using non-integer timestamps.  This prevents the display of rounding
errors for common values like days < 32.

using non-integer timestamps.  This prevents the display of rounding
errors for common values like days < 32.

correctly, style fixes.

working buffer into ParseDateTime() and reject too-long input there,
rather than checking the length of the input string before calling
ParseDateTime(). The old method was bogus because ParseDateTime() can use
a variable amount of working space, depending on the content of the
input string (e.g. how many fields need to be NUL terminated). This fixes
a minor stack overrun -- I don't _think_ it's exploitable, although I
won't claim to be an expert.

Along the way, fix a bug reported by Mark Dilger: the working buffer
allocated by interval_in() was too short, which resulted in rejecting
some perfectly valid interval input values. I added a regression test for
this fix.

scanner anyway) to avoid having any backup states.  According to the
flex manual, this should speed things up, and indeed the backend scanner
is about a third faster according to some quick profiling checks.
I haven't tried to measure the speed change in psql, but it probably
is similar.

error.

Pavel Stehule

using pg_mblen. Therefore, pg_mblen is executed many times, and it
becomes a bottleneck.

This patch makes a short cut, and reduces execution frequency of
pg_mblen by comparing the first byte first.

a_ogawa

about adding an errant "TO" when we already have a TO. Since
TO cannot be a valid column name (we must quote it), we can
simply ignore the tab-completion if the previous word
was a "TO".

Greg Sabino Mullane

them, the executation behavior could be unexpected.

where there was also a WHERE-clause restriction that applied to the
join.  The check on restrictlist == NIL is really unnecessary anyway,
because select_mergejoin_clauses already checked for and complained
about any unmergejoinable join clauses.  So just take it out.

Not sure why this hasn't been reported before; perhaps it is not needed
with newer gcc versions, but it definitely fails here.

if they are two-byte multibyte characters. Same thing can be happen
if octet_length(multibyte_chars) == n where n is char(n).
Long standing bug since 7.3 days. Per report and fix from Yoshiyuki Asaba.

Andrew Dunstan.

Log prepare query during execute.  Bruce Momjian

error condition when executing some DDL. Per report from ITAGAKI Takahiro.

#define SECS_PER_DAY  86400
#define USECS_PER_DAY INT64CONST(86400000000)
#define USECS_PER_HOUR    INT64CONST(3600000000)
#define USECS_PER_MINUTE INT64CONST(60000000)
#define USECS_PER_SEC INT64CONST(1000000)

that we acquire a lock on relations added to the query due to inheritance.
Formerly, no such lock was held throughout planning, which meant that
a schema change could occur to invalidate the plan before it's even
been completed.

sharing of %_SHARED. From Andrew Dunstan.

to the entire table: as of current sources, they are no longer slow
provided there is an index on the column.

function descriptions in func.sgml; other minor SGML tweaks.

aren't doing anything useful (ie, neither selection nor projection).
Also, extend to SubqueryScan the hacks already in place to avoid
unnecessary ExecProject calls when the result would just be the same
tuple the subquery already delivered.  This saves some overhead in
UNION and other set operations, as well as avoiding overhead for
unflatten-able subqueries.  Per example from Sokolov Yura.