< o Add long file support for binary pg_dump output
<
< While Win32 supports 64-bit files, the MinGW API does not,
< meaning we have to build an fseeko replacement on top of the
< Win32 API, and we have to make sure MinGW handles it. Another
< option is to wait for the MinGW project to fix it, or use the
< code from the LibGW32C project as a guide.
<
< http://archives.postgresql.org/pgsql-hackers/2006-12/msg00551.php
<
> o -Add long file support for binary pg_dump output
< Currently, ALTER USER and ALTER DATABASE support per-user and
> Currently ALTER USER and ALTER DATABASE support per-user and
< Currently, subtracting one date from another that crosses a
> Currently subtracting one date from another that crosses a
< Currently, SQL-language functions can only refer to parameters via $1, etc
> Currently SQL-language functions can only refer to dollar parameters,
> e.g. $1
< Currently, queries prepared via the libpq API are planned on first
> Currently queries prepared via the libpq API are planned on first
< Currently, SET <tab> causes a database lookup to check all
> Currently SET <tab> causes a database lookup to check all
< Currently, all statement results are transferred to the libpq
> Currently all statement results are transferred to the libpq
>
> o Allow row and record variables to be set to NULL constants,
> and allow NULL tests on such variables
>
> Because a row is not scalar, do not allow assignment
> from NULL-valued scalars.
< * Merge xmin/xmax/cmin/cmax back into three header fields
<
< Before subtransactions, there used to be only three fields needed to
< store these four values. This was possible because only the current
< transaction looks at the cmin/cmax values. If the current transaction
< created and expired the row the fields stored where xmin (same as
< xmax), cmin, cmax, and if the transaction was expiring a row from a
< another transaction, the fields stored were xmin (cmin was not
< needed), xmax, and cmax. Such a system worked because a transaction
< could only see rows from another completed transaction. However,
< subtransactions can see rows from outer transactions, and once the
< subtransaction completes, the outer transaction continues, requiring
< the storage of all four fields. With subtransactions, an outer
< transaction can create a row, a subtransaction expire it, and when the
< subtransaction completes, the outer transaction still has to have
< proper visibility of the row's cmin, for example, for cursors.
<
< One possible solution is to create a phantom cid which represents a
< cmin/cmax pair and is stored in local memory. Another idea is to
< store both cmin and cmax only in local memory.
<
> * -Merge xmin/xmax/cmin/cmax back into three header fields
< * Consider placing all sequences in a single table, now that system
< tables are full transactional
> * Consider placing all sequences in a single table
>
> * Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY
>
> This is difficult because you must upgrade to an exclusive table lock
> to replace the existing index file. CREATE INDEX CONCURRENTLY does not
> have this complication. This would allow index compaction without
> downtime.
discussions.
<
<
< ---------------------------------------------------------------------------
<
<
< Developers who have claimed items are:
< --------------------------------------
< * Alvaro is Alvaro Herrera <alvherre@dcc.uchile.cl>
< * Andrew is Andrew Dunstan <andrew@dunslane.net>
< * Bruce is Bruce Momjian <bruce@momjian.us> of EnterpriseDB
< * Christopher is Christopher Kings-Lynne <chriskl@familyhealth.com.au> of
< Family Health Network
< * D'Arcy is D'Arcy J.M. Cain <darcy@druid.net> of The Cain Gang Ltd.
< * David is David Fetter <david@fetter.org>
< * Fabien is Fabien Coelho <coelho@cri.ensmp.fr>
< * Gavin is Gavin Sherry <swm@linuxworld.com.au> of Alcove Systems Engineering
< * Greg is Greg Sabino Mullane <greg@turnstep.com>
< * Jan is Jan Wieck <JanWieck@Yahoo.com> of Afilias, Inc.
< * Joe is Joe Conway <mail@joeconway.com>
< * Karel is Karel Zak <zakkr@zf.jcu.cz>
< * Magnus is Magnus Hagander <mha@sollentuna.net>
< * Marc is Marc Fournier <scrappy@hub.org> of PostgreSQL, Inc.
< * Matthew T. O'Connor <matthew@zeut.net>
< * Michael is Michael Meskes <meskes@postgresql.org> of Credativ
< * Neil is Neil Conway <neilc@samurai.com>
< * Oleg is Oleg Bartunov <oleg@sai.msu.su>
< * Pavel is Pavel Stehule <pavel.stehule@hotmail.com>
< * Peter is Peter Eisentraut <peter_e@gmx.net>
< * Philip is Philip Warner <pjw@rhyme.com.au> of Albatross Consulting Pty. Ltd.
< * Rod is Rod Taylor <pg@rbt.ca>
< * Simon is Simon Riggs <simon@2ndquadrant.com>
< * Stephan is Stephan Szabo <sszabo@megazone23.bigpanda.com>
< * Tatsuo is Tatsuo Ishii <ishii@sraoss.co.jp> of SRA OSS, Inc. Japan
< * Teodor is Teodor Sigaev <teodor@sigaev.ru>
< * Tom is Tom Lane <tgl@sss.pgh.pa.us> of Red Hat
< * 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.
<
< * 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
>
> * Make consistent use of long/short command options --- pg_ctl needs
> long ones, pg_config doesn't have short ones, postgres doesn't have
> enough long ones, etc.
> o Consider parsing the -c string into individual queries so each
> is run in its own transaction
>
> o Consider disallowing multiple queries in PQexec() as an
> additional barrier to SQL injection attacks
< * Allow inherited tables to inherit index, UNIQUE constraint, and primary
< key, foreign key
< * UNIQUE INDEX on base column not honored on INSERTs/UPDATEs from
< inherited table: INSERT INTO inherit_table (unique_index_col) VALUES
< (dup) should fail
<
< The main difficulty with this item is the problem of creating an index
< that can span more than one table.
<
< * Allow SELECT ... FOR UPDATE on inherited tables
> * Inheritance
>
> o Allow inherited tables to inherit indexes, UNIQUE constraints,
> and primary/foreign keys
> o Honor UNIQUE INDEX on base column in INSERTs/UPDATEs
> on inherited table, e.g. INSERT INTO inherit_table
> (unique_index_col) VALUES (dup) should fail
>
> The main difficulty with this item is the problem of
> creating an index that can span multiple tables.
>
> o Allow SELECT ... FOR UPDATE on inherited tables
>
>
>
Bruce Momjian
Neil Conway