| Age | Commit message (Collapse) | Author |
|---|
|
|
|
FAMILY; and add FAMILY option to CREATE OPERATOR CLASS to allow adding a
class to a pre-existing family. Per previous discussion. Man, what a
tedious lot of cutting and pasting ...
|
|
|
|
columns procost and prorows, to allow simple user adjustment of the estimated
cost of a function call, as well as control of the estimated number of rows
returned by a set-returning function. We might eventually wish to extend this
to allow function-specific estimation routines, but there seems to be
consensus that we should try a simple constant estimate first. In particular
this provides a relatively simple way to control the order in which different
WHERE clauses are applied in a plan node, which is a Good Thing in view of the
fact that the recent EquivalenceClass planner rewrite made that much less
predictable than before.
|
|
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php
|
|
provide just a boolean 'amcanorder', instead of fields that specify the
sort operator strategy numbers. We have decided to require ordering-capable
AMs to use btree-compatible strategy numbers, so the old fields are
overkill (and indeed misleading about what's allowed).
|
|
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg01188.php
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00121.php
|
|
|
|
match the postgresql.conf file. Also add units to descriptions that
lacked them. Wording improvements. Mention pg_settings.unit as the way
to find the default units for setting.
Backpatch to 8.2.X.
|
|
|
|
representation of equivalence classes of variables. This is an extensive
rewrite, but it brings a number of benefits:
* planner no longer fails in the presence of "incomplete" operator families
that don't offer operators for every possible combination of datatypes.
* avoid generating and then discarding redundant equality clauses.
* remove bogus assumption that derived equalities always use operators
named "=".
* mergejoins can work with a variety of sort orders (e.g., descending) now,
instead of tying each mergejoinable operator to exactly one sort order.
* better recognition of redundant sort columns.
* can make use of equalities appearing underneath an outer join.
|
|
|
|
HTML in HTML mode. Patch from Jeremy Drake.
|
|
Backpatch to 8.2.
|
|
< first.
> first. There is also a developer's wiki at
> http://developer.postgresql.org.
|
|
> o Allow multiple vacuums so large tables do not starve small
> tables
>
> http://archives.postgresql.org/pgsql-general/2007-01/msg00031.php
>
> o Improve control of auto-vacuum
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00876.php
|
|
* Add Globally/Universally Unique Identifier (GUID/UUID)
> http://archives.postgresql.org/pgsql-general/2007-01/msg00853.php
|
|
with new GUC parameter "xmlbinary" that controls the output encoding, as
per SQL/XML standard.
|
|
|
|
declarations are ignored and removed, in binary mode they are honored as
specified by the XML standard.
|
|
|
|
The implementation is somewhat ugly logic-wise, but I don't see an
easy way to make it more concise.
When writing this, I noticed that my previous implementation of
width_bucket() doesn't handle NaN correctly:
postgres=# select width_bucket('NaN', 1, 5, 5);
width_bucket
--------------
6
(1 row)
AFAICS SQL:2003 does not define a NaN value, so it doesn't address how
width_bucket() should behave here. The patch changes width_bucket() so
that ereport(ERROR) is raised if NaN is specified for the operand or the
lower or upper bounds to width_bucket(). For float8, NaN is disallowed
for any of the floating-point inputs, and +/- infinity is disallowed
for the histogram bounds (but allowed for the operand).
Update docs and regression tests, bump the catversion.
|
|
|
|
roles and tablespaces, no longer users and groups. Per Dave Page.
Backport to 8.2 and 8.1.
|
|
Per recent -hackers thread, this is noteworthy because Postgres behaves
differently from most implementations of NaN, including IEEE754.
|
|
< o Fix memory leak from exceptions
<
< http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php
<
< * Allow constraint_exclusion to work for UNIONs like it does for
< inheritance, allow it to work for UPDATE and DELETE statements, and allow
< it to be used for all statements with little performance impact
<
< * Add estimated_count(*) to return an estimate of COUNT(*)
<
< This would use the planner ANALYZE statistics to return an estimated
< count.
< http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php
|
|
standard convention the 21st century runs from 2001-2100, not 2000-2099,
so make it work like that. Per bug #2885 from Akio Iwaasa.
Backpatch to 8.2, but no further, since this is really a definitional
change; users of older branches are probably more interested in stability.
|
|
|
|
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00291.php
|
|
> o Fix transaction restriction checks for CREATE DATABASE and
> other commands
>
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00133.php
|
|
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php
|
|
> o Extend timezone code to allow 64-bit values so we can
> represent years beyond 2038
>
> http://archives.postgresql.org/pgsql-hackers/2006-09/msg01363.php
>
|
|
> * Move NAMEDATALEN from postgres_ext.h to pg_config_manual.h and
> consider making it more configurable in future releases
|
|
|
|
Documentation/comment improvements.
|
|
|
|
|
|
>
> * Improve merge join performance by allowing mark/restore of
> tuple sources
>
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00096.php
>
|
|
which was obsoleted by RFC 3629.
Michael Fuhr
|
|
indexes; add 'draft' option to disable it.
|
|
|
|
> * -Add ability to monitor the use of temporary sort files
|
|
Bill Moran
|
|
out the common error that ORDER BY x, y DESC does not mean the same as
ORDER BY x DESC, y DESC.
|
|
< * Allow the creation of indexes with mixed ascending/descending
> * -Allow the creation of indexes with mixed ascending/descending
<
< This is possible now by creating an operator class with reversed sort
< operators. One complexity is that NULLs would then appear at the start
< of the result set, and this might affect certain sort types, like
< merge join.
<
|
|
per-column options for btree indexes. The planner's support for this is still
pretty rudimentary; it does not yet know how to plan mergejoins with
nondefault ordering options. The documentation is pretty rudimentary, too.
I'll work on improving that stuff later.
Note incompatible change from prior behavior: ORDER BY ... USING will now be
rejected if the operator is not a less-than or greater-than member of some
btree opclass. This prevents less-than-sane behavior if an operator that
doesn't actually define a proper sort ordering is selected.
|
|
|
|
|
|
< * %Allow the identifier length to be increased via a configure option
|
|
< * Improve the MONEY data type
> * -Make 64-bit version of the MONEY data type
> * Add locale-aware MONEY type, and support multiple currencies
< Change the MONEY data type to use DECIMAL internally, with special
< locale-aware output formatting.
< http://archives.postgresql.org/pgsql-hackers/2006-09/msg01107.php
|
