PostgreSQL wiki - User contributions [en]

Switching PostgreSQL documentation from SGML to XML

2013-05-22T02:59:30Z

Petere: /* Arguments on SGML vs XML */

For about the last 10 years, there have been occasional discussions about switching the PostgreSQL documentation from SGML to XML (whatever that might mean). Here are some points to consider.

== Technical points ==
There is a distinction between changing the source format from SGML to XML versus switching the tool chain from DSSSL to XSLT. Even though DSSSL is typically associated with SGML and XSLT with XML, in fact all combinations work more or less equally well.

== Arguments on SGML vs XML ==
* DocBook 5, the next major version, will no longer publish an SGML DTD. But DocBook 5 has been in the works for years and it might be many more years until it is the standard version and all previous versions have disappeared.
* SGML is easier to edit than XML, because of tag minimization and some other simplifications.
* SGML supports conditional sections (used to build the INSTALL file, for example). That needs a different solution for XML.
* There might be more editing tools that support XML, but this needs to be substantiated.
* Translation teams are using XML.
* We'd probably want to rename *.sgml -> *.xml. Easier now with Git, but needs some planning.
* With xmllint, we could a sort of pgindent on the documentation.

== Arguments on DSSSL vs XSLT ==
* The DSSSL tools have been unmaintained for years.
* Small question marks on FOP (XSLT to PDF tool): Is it maintained, is there a stable version (as opposed to endless development pre-releases), can it run on an entirely free Java installation? Should dblatex be used instead of FOP?
* The customizations that we have done to the DSSSL stylesheets would have to be ported to XSLT. This work could start already.
* The XSLT build is currently a ''lot'' slower than the DSSSL build.
* XSLT might offer more flexibility such as partial builds.
* There are more tools that work with XSLT in various ways.

== Formats We Generate ==

A compleat solution needs to be able to generate all of the following output forms,
* HTML
* Manual pages
* RTF
* PDF and Postscript
** A4 format
** US format
* TeXinfo

== Toolchain Components ==
In order to do a switchover, it will be necessary to replace all of the components. It is worth enumerating these components, so that nobody makes the error of thinking that some partial solution to one part represents a complete solution.

; docbook-utils
: Consists of scripts that transform DocBook into some useful forms (html, pdf, rtf, man pages)
; docbook-dsssl
: These are the DSSSL stylesheets used to render DocBook into various output forms. They might be replaced by XSLT stylesheets.
; jade
: A DSSSL engine
; openjade
: An alternative DSSSL engine
; jadetex
: A DSSSL engine generating TeX-based output

[[Category:Development]]

PgCon 2013 Developer Meeting

2013-04-15T20:07:22Z

Petere: /* Proposed Agenda Items */ Add names, based on history

A meeting of the most active PostgreSQL developers is being planned for Wednesday 22nd May, 2013 near the University of Ottawa, prior to pgCon 2013. In order to keep the numbers manageable, this meeting is '''by invitation only'''. Unfortunately it is quite possible that we've overlooked important code developers during the planning of the event - if you feel you fall into this category and would like to attend, please contact Dave Page (dpage@pgadmin.org).

Please note that this year the attendee numbers have been kept low in order to keep the meeting more productive. Invitations have been sent only to developers that have been highly active on the database server over the 9.3 release cycle. We have not invited any contributors based on their contributions to related projects, or seniority in regional user groups or sponsoring companies, unlike in previous years.

This is a PostgreSQL Community event. Room and refreshments/food sponsored by EnterpriseDB. Other companies sponsored attendance for their developers.

== Time & Location ==

The meeting will be from 8:30AM to 5PM, and will be in the "Red Experience" room at:

Novotel Ottawa
33 Nicholas Street
Ottawa
Ontario
K1N 9M7

Food and drink will be provided throughout the day, including breakfast from 8AM.

[http://maps.google.ca/maps?f=q&source=s_q&hl=en&geocode=&q=novotel+ottawa&aq=&sll=49.891235,-97.15369&sspn=36.237851,79.013672&ie=UTF8&hq=novotel+ottawa&hnear=&ll=45.421528,-75.683699&spn=0.036869,0.077162&z=14&iwloc=A&layer=c&cbll=45.425741,-75.689638&panoid=Z4FUGnkZkdHAOkIxyjjS9Q&cbp=12,25.83,,0,-0.6 View on Google Maps]

== Attendees ==

The following people have RSVPed to the meeting (in alphabetical order, by surname):

* Jeff Davis
* Andrew Dunstan
* Peter Eisentraut
* Dimitri Fontaine
* Andres Freund
* Stephen Frost
* Peter Geoghegan
* Kevin Grittner
* Robert Haas
* Magnus Hagander
* Fujii Masao
* Noah Misch
* Bruce Momjian
* Tom Lane
* Dave Page
* Simon Riggs
* KaiGai Kohei

== Proposed Agenda Items ==

Please list proposed agenda items here:

* 9.4 Commitfest schedule
* [http://wiki.postgresql.org/wiki/Parallel_Query_Execution Parallel Query Execution] (Bruce)
* logical changeset generation review & integration (Andres)
* utilization of upcoming non-volatile RAM device (Kaigai)
* pluggable plan/exec nodes (Kaigai)
** to offload targetlist calculation, sorting, aggregates, ...

Homebrew

2013-04-09T02:20:49Z

Petere: Added petere/postgresql tap

[http://mxcl.github.com/homebrew/ Homebrew] is a package manager for Mac OS X that builds software from its source code. It includes a version of PostgreSQL packaged by what it refers to as a formula. This type of installation might be preferred by people who are comfortable using the command line to install programs, such as software developers.

Notes on Homebrew:

* [http://russbrooks.com/2010/11/25/install-postgresql-9-on-os-x Install PostgreSQL 9 on OS X] (2010-11-25) - Easy install using Homebrew package manager.
* [http://nextmarvel.net/blog/2011/09/brew-install-postgresql-on-os-x-lion/ Brew Install Postgresql on OS X Lion] - Resolving conflicts with the built-in PostgreSQL libraries shipping with OS X 10.7 'Lion'
* [http://archives.postgresql.org/pgsql-hackers/2012-04/msg00010.php Discussion comparing Homebrew and EDB OS X installers]
* [https://github.com/petere/homebrew-postgresql <code>petere/postgresql</code>] tap for installing multiple PostgreSQL versions in parallel

[[Category:Tool]]

PGDay NYC 2013 Talks

2013-03-25T18:37:24Z

Petere: Add my talk

= PGDay NYC 2013 Talks =

== Friday March 22nd, 2013 ==

=== Liberty Hall C ===

* [http://momjian.us/main/writings/pgsql/locking.pdf Understanding the Postgres Lock Manager (Bruce Momjian)]
* [http://plv8-talk.herokuapp.com/ Embracing the Web with JSON and PLV8 (Will Leinweber)]

=== Liberty Hall A ===

* [[:File:PPCD.pdf|Postgres Plus Cloud Database (Dave Page)]]
* [https://github.com/petere/logging-hooks-presentation Toward real-time log analysis (Peter Eisentraut)]

[[Category:PostgreSQL Events]]

NLS

2012-10-30T18:44:52Z

Petere: /* Translating */

= PostgreSQL National Language Support =

This page contains some information about the PostgreSQL National Language Support effort. Please read the [http://developer.postgresql.org/docs/postgres/nls.html information about NLS in the PostgreSQL Documentation] for background and technical information. Some of the information on this page may eventually be migrated there as it stabilizes. There's also the [http://www.gnu.org/software/gettext/manual/gettext.html GNU Gettext Manual], which is only partially relevant for us, but it might be good to look at anyway.

== Status ==

The [http://babel.postgresql.org/ status tables] shows which areas of the PostgreSQL source are prepared for translation, and the progress of those translations. There you can also download freshly baked PO files that are merged up against the latest program sources. No PostgreSQL source tree is needed for translation work.

== Communicating ==

If you have any questions about the PostgreSQL translation project, including
* you want to start a new translation or continue an existing one and you want to avoid duplicating your work with someone else,
* you're looking for other people who want to work with you on translating,
* you're having technical questions about tools, the source tree, the meaning of terms, etc.,
then write to the mailing list mailto:pgtranslation-translators@pgfoundry.org. More information about our [http://pgfoundry.org/mail/?group_id=1000064 mailing lists] is available.

== Howto ==

Here is how to get set up for translation work. It is assumed here that you already know your way around gettext message catalogs. If you're new to this, read the chapter on NLS in the PostgreSQL Documentation.

=== Translating ===

# To continue an existing translation, download a new PO file by following the links in the [http://babel.postgresql.org/ status tables]. Fill in the file as much as you want.
# To start a new translation, download a POT file by clicking on one of the catalog names in the left column of the [http://babel.postgresql.org/ status tables]. First, fill in all the fields in the header and remove the fuzzy flag. Particularly, the character set information is very important and must not be left out! Then fill in the rest of the file as much as you want.
# When you are done editing, check the file for errors. If you're using the Emacs PO mode, press V. From the command line, run <code>msgfmt -o /dev/null -v -c yourfile.po</code>. Or copy the file into the main PostgreSQL source tree and run <code>gmake maintainer-check-po</code>. If you don't do this, your file might contain bugs that cause program crashes, which will quickly disenchant users from PostgreSQL and internationalized software in general.
# Submit the resulting file to the [http://pgfoundry.org/tracker/?atid=320&group_id=1000064 Patch Tracker]. Please do not send patches; send the whole file. If you're concerned that the file is too big, run it through a compression program. If you are sending many files, put them into a tar archive. Please don't open a ticket per file, or create many attachments. Both of these rules make it easier for the person installing your files. One of the registered developers will install your file into the source code repository. Make sure you specify which branch your file is for (see below about branches). People who have contributed for a while will be registered as developers and are able to commit their files into the source code repository by themselves.

=== Tools ===

Please don't edit the PO files with a plain text editor. You're making your life unnecessarily hard. There are several tools that make editing PO files really easy.
* GNU Emacs and XEmacs have PO editing modes.
* [http://kbabel.kde.org/ KBabel] is for those who like KDE-based tools.
* [http://www.poedit.net/ Poedit] is yet another tool, which even works under Windows

=== Team Building ===

If you are new, please check on the [http://babel.postgresql.org/ status tables] whether your language is already being worked on. If so, look into the translation files near the top to find out where to contact the last translator or the translation team. Please contact them about contributing. If the last translator cannot be reached or if it has been a long time since the last update to the file, you can just take over. But remember that communicating first avoids duplicate work later.

=== Tips ===

Check out the home of the [http://translationproject.org/html/welcome.html GNU Translation Project]. There you can find out about mailing lists, web sites, and other resources for translation efforts to your language. Some of these resources are GNU-oriented, but others are not.

== Release Management ==

You can work in several branches. There is a current branch and several back branches.

The back branches belong to past releases of PostgreSQL. It is usually a good idea to finish translations for the recent back branches first, because those are the ones that people currently use. When a new back branch release is made (something like 8.0.5 or 8.1.1), updated translations will be included.

By contrast, the current branch is often under heavy development, meaning that error messages change, and translation work done today might become obsolete tomorrow. Therefore, translations in the current branch should normally only be done during the beta phase or after a release if no new branch for the development release has been made yet. (The [http://babel.postgresql.org/ status page] informs about the status of the branches.)

Information about release schedules and so on will also be posted to the mailing list mailto:pgtranslation-translators@pgfoundry.org (see [http://pgfoundry.org/mail/?group_id=1000064 mailing lists]), which you are encouraged to read.

=== Minimum Translation ===

A PO file must have at least 80% of its strings translated before it is considered for inclusion in a PostgreSQL major release. This is to prevent presenting users with a strange mix of English and non-English messages. This criterion will be regularly evaluated in the time before a major release, in particular during the beta phase. Files that do not meet this criterion will not be included or removed if they have previously been included.

If a file drops below the threshold after the major release during the maintenance period of a branch, it will not be removed because of that.

This is a new policy as of April 2009; we will see how it goes.

[[Category:Development]]

Oracle Compatibility Tasks

2012-06-30T17:07:26Z

Petere: remove done stuff

= Implementation Jobs for Improving Oracle Compatibility in PostgreSQL =

Here are a few jobs and research projects for improving Oracle compatibility in and around PostgreSQL. This is based upon [http://www.pgcon.org/2008/schedule/events/62.en.html Peter Eisentraut's talk at PGCon 2008]. Please add your thoughts.

== Syntax ==

* Quoted identifiers, upper vs. lower case folding

* MINUS vs. EXCEPT (check whether Oracle also supports EXCEPT)

== Data Types ==

* Implement varchar2 as alias for varchar [orafce]

* Implement clob as alias for text [PG core]

* Implement long as alias for text or clob? [orafce]

* Implement nchar, nvarchar2, nclob as appropriate [orafce and PG core]

* Implement number as alias for numeric [orafce]

* Implement binary_float, binary_double as aliases for float4, float8 [orafce]

* Implement blob [PG core]

* Implement raw, long raw [orafce]

* Figure out some way to allow Oracle-behavior with date (???)

* Fix interval type to be compatible with SQL standard.

== Null Behavior ==

I would like to see a detailed analysis and definition of how null values
really behave in Oracle. We can probably implement workarounds to make the
behavior optionally more similar, but at the moment the Oracle behavior just
appears weird and totally inconsistent.

== Sequences ==

* Add NOCACHE clause to CREATE SEQUENCE

== Formatting ==

* Add more features and robustness to to_char.

* Maybe add custom variables for the NLS_ settings that internally change the right PostgreSQL settings.

== Triggers ==

* Allow creating triggers and associated functions in one statement. The function would be created automatically as a depend

== PL/pgSQL ==

* Make DECLARE optional

* Make PERFORM optional for procedure calls

[[Category:Oracle]]

User:Petere

2012-06-30T17:04:18Z

Petere: remove old stuff

=Peter Eisentraut's PostgreSQL Activities=

These pages contain some information about my activities related to the PostgreSQL project. If you want to follow what I'm up to, check my [http://petereisentraut.blogspot.com/ blog] or follow me on [http://twitter.com/petereisentraut Twitter].

==Long-term Projects==
* [[Usability Challenges]]
* [[Oracle Compatibility Tasks]]

==Publishing==

I have written a few books about PostgreSQL:
* [http://www.oreilly.de/catalog/postgresqladmger/ PostgreSQL-Administration], 2009
* [http://mitp.de/vmi/mitp/detail/pWert/1493 PostgreSQL GE-PACKT], 2005
* [http://mitp.de/vmi/mitp/detail/pWert/513371 PostgreSQL: Das offizielle Handbuch], 2003 (also available [http://www.postgresql.org/docs/books/pghandbuch.html.de online])

See also the [http://www.postgresql.org/docs/books/ PostgreSQL book list].

FAQ

2012-06-17T08:34:20Z

Petere: Add: Why do my strings sort incorrectly?

{{Languages}}
[[:Category:FAQ|Additional FAQ Entries on this Wiki]]

== Translations of this Document ==

* [[Häufig gestellte Fragen|German]]
* [[Perguntas Frequentes|Portuguese]]
* [[Preguntas Frecuentes|Spanish]]
* [[Часто Задаваемые Вопросы|Русский]]

== Platform-specific questions ==

Windows users should also read the [[Running & Installing PostgreSQL On Native Windows|platform FAQ for Windows]]. There are [[Frequently Asked Questions#Platform FAQs|FAQs for other platforms]] too.

== General Questions ==

=== What is PostgreSQL? How is it pronounced? What is Postgres? ===

PostgreSQL is pronounced Post-Gres-Q-L. (For those curious about how
to say "PostgreSQL", an [http://www.postgresql.org/files/postgresql.mp3 audio file] is available.)

PostgreSQL is an object-relational database system that has the
features of traditional proprietary database systems with enhancements
to be found in next-generation DBMS systems. PostgreSQL is free and
the complete source code is available.

PostgreSQL development is performed by a team of mostly volunteer
developers spread throughout the world and communicating via the
Internet. It is a community project and is not controlled by any
company. To get involved, see the [[Developer_FAQ | Developer FAQ]].

Postgres is a widely-used nickname for PostgreSQL. It was the original
name of the project at Berkeley and is strongly preferred over other
nicknames. If you find 'PostgreSQL' hard to pronounce, call it
'Postgres' instead.

=== Who controls PostgreSQL? ===

If you are looking for a PostgreSQL gatekeeper, central committee, or
controlling company, give up --- there isn't one. We do have a core
committee and CVS committers, but these groups are more for
administrative purposes than control. The project is directed by the
community of developers and users, which anyone can join. All you need
to do is subscribe to the mailing lists and participate in the
discussions. (See the [[Developer FAQ|Developer's FAQ]] for information on how to get
involved in PostgreSQL development.)

=== Who is the PostgreSQL Global Development Group? ===

The "PGDG" is an international, unincorporated association of
individuals and companies who have contributed to the PostgreSQL
project. The PostgreSQL Core Team generally act as spokespeople
for the PGDG.

=== Who is the PostgreSQL Core Team? ===

A committee of five to seven (currently six) senior contributors to
PostgreSQL who do the following for the project: (a) set release dates,
(b) handle confidential matters for the project, (c) act as spokespeople
for the PGDG when required, and (d) arbitrate community decisions which
are not settled by consensus. The current Core Team is listed on top of
[http://www.postgresql.org/community/contributors/ the contributors page]

=== What about the various PostgreSQL foundations? ===

While the PostgreSQL project utilizes non-profit corporations in the
USA, Europe, Brazil and Japan for fundraising and project coordination,
these entities do not own the PostgreSQL code.

=== What is the license of PostgreSQL? ===

PostgreSQL is distributed under a license similar to BSD and MIT. Basically, it
allows users to do anything they want with the code, including
reselling binaries without the source code. The only restriction is
that you not hold us legally liable for problems with the software.
There is also the requirement that this copyright appear in all copies
of the software. Here is the license we use:

PostgreSQL Database Management System
(formerly known as Postgres, then as Postgres95)

Portions Copyright (c) 1996-2011, PostgreSQL Global Development Group

Portions Copyright (c) 1994, The Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written agreement
is hereby granted, provided that the above copyright notice and this
paragraph and the following two paragraphs appear in all copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS
DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO
PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

=== What platforms does PostgreSQL support? ===

In general, any modern Unix-compatible platform should be able to run
PostgreSQL. The platforms that have received recent explicit testing
can be seen in the [http://buildfarm.postgresql.org/ Build farm].
The documentation contains more details about supported platforms at http://www.postgresql.org/docs/current/static/supported-platforms.html.

PostgreSQL also runs natively on Microsoft Windows NT-based operating
systems like Win2000 SP4, WinXP, and Win2003. A prepackaged installer
is available at http://www.postgresql.org/download/windows.
MSDOS-based versions of Windows (Win95, Win98, WinMe) can run
PostgreSQL using Cygwin.

=== Where can I get PostgreSQL? ===

There are binary distributions for various operating systems and platforms; see [http://www.postgresql.org/download our download area].

The source code can be obtained [http://www.postgresql.org/ftp/ via web browser] or [ftp://ftp.postgresql.org/pub/ through ftp].

=== What is the most recent release? ===

The latest release of PostgreSQL is shown on the front page of [http://www.postgresql.org/ our website].

We typically have a major release every year, with minor releases every few months.
Minor releases are usually made at the same time for all supported major-release branches.
For more about major versus minor releases, see
http://www.postgresql.org/support/versioning.

=== Where can I get support? ===

The PostgreSQL community provides assistance to many of its users via
email. The main web site to subscribe to the email lists is
http://www.postgresql.org/community/lists/. The general or bugs lists
are a good place to start. For best results, consider reading the
[[guide to reporting problems]] before you post to make sure you
include enough information for people to help you.

The major IRC channel is #postgresql on Freenode (irc.freenode.net).
A Spanish one also
exists on the same network, (#postgresql-es), a French one,
(#postgresqlfr), and a Brazilian one, (#postgresql-br). There is also
a PostgreSQL channel on EFNet.

A list of support companies is available at
http://www.postgresql.org/support/professional_support.

=== How do I submit a bug report? ===

Visit the PostgreSQL bug form at
http://www.postgresql.org/support/submitbug to submit your bug
report to the pgsql-bugs mailing list. Also check out our ftp
site ftp://ftp.postgresql.org/pub/ to see if there is a more recent
PostgreSQL version.

For a prompt and helpful response, it is important for you to read the
[[guide to reporting problems]] to make sure that you include the
information required to fully understand and act on your report.

Bugs submitted using the bug form or posted to any PostgreSQL mailing
list typically generates one of the following replies:
* It is not a bug, and why
* It is a known bug and is already on the TODO list
* The bug has been fixed in the current release
* The bug has been fixed but is not packaged yet in an official release
* A request is made for more detailed information:
** Operating system
** PostgreSQL version
** Reproducible test case
** Debugging information
** [[Generating_a_stack_trace_of_a_PostgreSQL_backend|Debugger backtrace output]]
* The bug is new. The following might happen:
** A patch is created and will be included in the next major or minor release
** The bug cannot be fixed immediately and is added to the TODO list

=== How do I find out about known bugs or missing features? ===

PostgreSQL supports an extended subset of SQL:2008. See our [[Todo|TODO list]]
for known bugs, missing features, and future plans.

A feature request usually results in one of the following replies:
* The feature is already on the TODO list
* The feature is not desired because:
** It duplicates existing functionality that already follows the SQL standard
** The feature would increase code complexity but add little benefit
** The feature would be insecure or unreliable
* The new feature is added to the TODO list

PostgreSQL does not use a bug tracking system because we find it more
efficient to respond directly to email and keep the TODO list
up-to-date. In practice, bugs don't last very long in the software,
and bugs that affect a large number of users are fixed rapidly. The
only place to find all changes, improvements, and fixes in a
PostgreSQL release is to read the CVS log messages. Even the release
notes do not list every change made to the software.

=== A bug I'm encountering is fixed in a newer minor release of PostgreSQL, but I don't want to upgrade. Can I get a patch for just this issue? ===

No. Nobody will make a custom patch for you so you can (say) extract a fix from 8.4.3 and apply it to 8.4.1 .
That's because there should never be any need to do that.

PostgreSQL has a strict policy that only bug fixes are back-patched into point releases, as per the [http://www.postgresql.org/support/versioning version policy]. It is safe to upgrade from 8.4.1 to 8.4.3,
for example. Binary compatibility will be maintained, no dump and reload is required, nothing will break, but bugs that might
cause problems have been fixed. Even if you are not yet encountering a particular bug, you might later, and it is wise to upgrade promptly.
You just have to install the update and re-start the database server, nothing more.

Upgrading from 8.3 to 8.4, or 8.4 to 9.0, is a major upgrade that does not come with the same guarantees. However, if a bug
is discovered in 9.0 then it will generally be fixed in all maintained older versions like 8.4 and 8.3 if it is safe and
practical to do so.

This means that if you're running 8.1.0, upgrading to 8.1.21 is <b>strongly</b> recommended and very safe. On the other hand,
upgrading to the next major release, 8.2.x, may require changes to your app, and will certainly require a dump and reload.

If you want to be careful about all upgrades, you should read the [http://www.postgresql.org/docs/current/static/release.html release notes]
for each point release between your current one and the latest minor version of the same major release carefully. If you're
exceptionally paranoid about upgrades, you can fetch the source code to each set of point release changes from [http://git.postgresql.org/ PostgreSQL's git repository] and examine it.

It is strongly recommended that you <b>always</b> upgrade to the latest minor release. Avoid trying to extract and apply individual fixes
from point releases; by doing so you're bypassing all the QA done by the PostgreSQL team when they prepare a release, and are creating your
own custom version that <i>nobody else has ever used</i>. It's a lot safer to just update to the latest tested, safe release. <i>Patching your own custom, non-standard build will also take more time/effort, and will require the same amount of downtime as a normal upgrade.</i>

=== I have a program that says it wants PostgreSQL x.y.1. Can I use PostgreSQL x.y.2 instead? ===

Any program that works with a particular version, like 8.4.1, should work with any other minor version in the same major version. That means that if a program says it wants (eg) 8.4.1, you can and should install the latest in the 8.4 series instead.

See the previous question for more details.

=== What documentation is available? ===

PostgreSQL includes extensive documentation, including a large manual,
manual pages, and some test examples. See the /doc directory. You can
also browse the manuals online at http://www.postgresql.org/docs.

There are a number of PostgreSQL
books available for purchase; two of them are also available online. A list of books can be found at
http://www.postgresql.org/docs/books/. One of the most popular ones is the one by Korry & Susan
Douglas.

There is also a collection of
PostgreSQL technical articles on the
[[Community_Generated_Articles%2C_Guides%2C_and_Documentation | wiki]].

The command line client program psql has some \d commands to show
information about types, operators, functions, aggregates, etc. - use
\? to display the available commands.

=== How can I learn SQL? ===

First, consider the PostgreSQL-specific books mentioned above. Many of
our users also like The Practical SQL Handbook, Bowman, Judith S., et
al., Addison-Wesley. Others like The Complete Reference SQL, Groff et
al., McGraw-Hill.

Many people consider the PostgreSQL documentation to be an excellent guide
for learning SQL its self, as well as for PostgreSQL's implementation of it.
For best results use PostgreSQL alongside another full-featured SQL database as
you learn, so you get used to SQL without becoming reliant on PostgreSQL-specific
features. The PostgreSQL documentation generally mentions when features are PostgreSQL
extensions of the standard.

There are also many nice tutorials available online:
* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html
* http://sqlzoo.net

=== How do I submit a patch or join the development team? ===

See the [[Developer FAQ|Developer's FAQ]].

=== How does PostgreSQL compare to other DBMSs? ===

There are several ways of measuring software: features, performance,
reliability, support, and price.

==== Features ====

PostgreSQL has most features present in large proprietary DBMSs,
like transactions, subselects, triggers, views, foreign key
referential integrity, and sophisticated locking. We have some
features they do not have, like user-defined types,
inheritance, rules, and multi-version concurrency control to
reduce lock contention.

==== Performance ====

PostgreSQL's performance is comparable to other proprietary and
open source databases. It is faster for some things, slower for
others. Our performance is usually +/-10% compared to other databases.

==== Reliability ====

We realize that a DBMS must be reliable, or it is worthless. We
strive to release well-tested, stable code that has a minimum
of bugs. Each release has at least one month of beta testing,
and our release history shows that we can provide stable, solid
releases that are ready for production use. We believe we
compare favorably to other database software in this area.

==== Support ====

Our mailing lists provide contact with a large group of
developers and users to help resolve any problems encountered.
While we cannot guarantee a fix, proprietary DBMSs do not always
supply a fix either. Direct access to developers, the user
community, manuals, and the source code often make PostgreSQL
support superior to other DBMSs. There is commercial
per-incident support available for those who need it. (See [[#Where_can_I_get_support.3F | section 1.7]]).

==== Price ====

We are free for all use, both proprietary and open source.
You can add our code to your product with no limitations,
except those outlined in our BSD-style license stated above.

=== Can PostgreSQL be embedded? ===

PostgreSQL is designed as a client/server architecture, which requires
separate processes for each client and server, and various helper
processes. Many embedded architectures can support such requirements.
However, if your embedded architecture requires the database server to
run inside the application process, you cannot use Postgres and should
select a lighter-weight database solution.

Popular embeddable options include [http://sqlite.org SQLite] and [http://firebirdsql.org Firebird SQL].

=== How do I unsubscribe from the PostgreSQL email lists? How do I avoid receiving duplicate emails? ===

The PostgreSQL Majordomo page allows subscribing or unsubscribing from
any of the PostgreSQL email lists. (You might need to have your
Majordomo password emailed to you to log in.)

All PostgreSQL email lists are configured so a group reply goes to the
email list and the original email author. This is done so users
receive the quickest possible email replies. If you would prefer not
to receive duplicate email from the list in cases where you already
receive an email directly, check eliminatecc from the Majordomo Change
Settings page. You can also prevent yourself from receiving copies of
emails you post to the lists by unchecking selfcopy.

== User Client Questions ==

=== What interfaces are available for PostgreSQL? ===

The PostgreSQL install includes only the C and embedded C interfaces.
All other interfaces are independent projects that are downloaded
separately; being separate allows them to have their own release
schedule and development teams.

Some programming languages like PHP include an interface to
PostgreSQL. Interfaces for languages like Perl, TCL, Python, and many
others are available at http://pgfoundry.org.

=== What tools are available for using PostgreSQL with Web pages? ===

A nice introduction to Database-backed Web pages can be seen at:
http://www.webreview.com

For Web integration, PHP (http://www.php.net) is an excellent
interface.

For complex cases, many use the Perl and DBD::Pg with CGI.pm or
mod_perl.

=== Does PostgreSQL have a graphical user interface? ===

There are a large number of GUI Tools that are available for
PostgreSQL from both proprietary and open source developers. A detailed
list can be found in the [[Community Guide to PostgreSQL GUI Tools]].

== Administrative Questions ==

=== How do I install PostgreSQL somewhere other than /usr/local/pgsql? ===

Specify the --prefix option when running configure.

=== I'm installing PostgreSQL and don't know the password for the postgres user ===

Dave Page wrote a [http://pgsnake.blogspot.com/2010/07/postgresql-passwords-and-installers.html blog post] explaining what the different passwords are used for, and how to overcome common problems such as resetting them.

=== How do I control connections from other hosts? ===

By default, PostgreSQL only allows connections from the local machine
using Unix domain sockets or TCP/IP connections. Other machines will
not be able to connect unless you modify listen_addresses in the
postgresql.conf file, enable host-based authentication by modifying
the $PGDATA/pg_hba.conf file, and restart the database server.

=== How do I tune the database engine for better performance? ===

There are three major areas for potential performance improvement:

==== Query Changes ====
This involves modifying queries to obtain better performance:

* Creation of indexes, including expression and partial indexes
* Use of COPY instead of multiple INSERTs
* Grouping of multiple statements into a single transaction to reduce commit overhead
* Use of CLUSTER when retrieving many rows from an index
* Use of LIMIT for returning a subset of a query's output
* Use of Prepared queries
* Use of ANALYZE to maintain accurate optimizer statistics
* Regular use of VACUUM or pg_autovacuum
* Dropping of indexes during large data changes

==== Server Configuration ====
A number of postgresql.conf settings affect performance. For
more details, see Administration Guide/Server Run-time
Environment/Run-time Configuration.

==== Hardware Selection ====
The effect of hardware on performance is detailed in
http://www.powerpostgresql.com/PerfList/ and
http://momjian.us/main/writings/pgsql/hw_performance/index.html.

=== What debugging features are available? ===

There are many log_* server configuration variables at http://www.postgresql.org/docs/current/interactive/runtime-config-logging.html that enable printing of query and process statistics which can be very useful for debugging and performance measurements.

=== Why do I get "Sorry, too many clients" when trying to connect? ===

You have reached the default limit of 100 database sessions. You need
to increase the server's limit on how many concurrent backend
processes it can start by changing the max_connections value in
postgresql.conf and restarting the server.

=== What is the upgrade process for PostgreSQL? ===

See http://www.postgresql.org/support/versioning for a general
discussion about upgrading, and
http://www.postgresql.org/docs/current/static/install-upgrading.html
for specific instructions.

=== Will PostgreSQL handle recent daylight saving time changes in various countries? ===

PostgreSQL releases 8.0 and up depend on the widely-used tzdata database
(also called the zoneinfo database or the [http://www.twinsun.com/tz/tz-link.htm Olson timezone database]) for
daylight savings information. To deal with a DST law change that affects you,
install a new tzdata file set and restart the server.

All PostgreSQL update releases include the latest available tzdata files,
so keeping up-to-date on minor releases for your major version is usually
sufficient for this.

On platforms that receive regular software updates including new tzdata files,
it may be more convenient to rely on the system's copy of the tzdata files.
This is possible as a compile-time option. Most Linux distributions choose
this approach for their pre-built versions of PostgreSQL.

PostgreSQL releases before 8.0 always rely on the operating system's timezone
information.

=== What computer hardware should I use? ===

Because PC hardware is mostly compatible, people tend to believe that
all PC hardware is of equal quality. It is not. ECC RAM, SCSI, and
quality motherboards are more reliable and have better performance
than less expensive hardware. PostgreSQL will run on almost any
hardware, but if reliability and performance are important it is wise
to research your hardware options thoroughly.

Database servers, unlike many other applications, are usually I/O and memory constrained, so it is wise to focus on the I/O subsystem first, then memory capacity, and lastly consider CPU issues. For example, a disk controller with a
battery-backed cache is often the cheapest and easiest way to improve database performance. Our email lists can be used to discuss hardware options and tradeoffs.

=== How does PostgreSQL use CPU resources? ===

The PostgreSQL server is process-based (not threaded), and uses one operating system process per database session. A single database session (connection) cannot utilize more than one CPU. Of course, multiple sessions are automatically spread across all available CPUs by your operating system. Client applications can easily use threads and create multiple database connections from each thread.

A single complex and CPU-intensive query is unable to use more than one CPU to do the processing for the query. The OS may still be able to use others for disk I/O etc, but you won't see much benefit from more than one spare core.

=== Why does PostgreSQL have so many processes, even when idle? ===

As noted in [[FAQ#How does PostgreSQL use CPU resources?|the answer above]], PostgreSQL is process based, so it starts one <code>postgres</code> (or <code>postgres.exe</code> on Windows) instance per connection. The postmaster (which accepts connections and starts new postgres instances for them) is always running. In addition, PostgreSQL generally has one or more "helper" processes like the stats collector, background writer, autovacuum daemon, walsender, etc, all of which show up as "postgres" instances in most system monitoring tools.

Despite the number of processes, they actually use very little in the way of real resources. See [[FAQ#Why does PostgreSQL show up as using so much memory in my system monitoring tool?|the next answer]].

=== Why does PostgreSQL use so much memory? ===

Despite appearances, this is absolutely normal, and there's actually nowhere near as much memory being used as tools like <code>top</code> or the Windows process monitor say PostgreSQL is using.

Tools like <code>top</code> and the Windows process monitor may show many <code>postgres</code> instances (see above), each of which appears to use a huge amount of memory. Often, when added up, the amount the postgres instances use is many times the amount of memory actually installed in the computer!

This is a consequence of how these tools report memory use. They generally don't understand shared memory very well, and show it as if it was memory used individually and exclusively by each postgres instance. PostgreSQL uses a big chunk of shared memory to communicate between its backends and cache data. Because these tools count that shared memory block once per <code>postgres</code> instance instead of counting it once for <i>all</i> <code>postgres</code> instances, they massively over-estimate how much memory PostgreSQL is using.

Furthermore, many versions of these tools don't report the entire shared memory block as being used by an individual instance immediately when it starts, but rather count the number of shared pages it has touched since starting. Over the lifetime of an instance, it will inevitably touch more and more of the shared memory until it has touched every page, so that its reported usage will gradually rise to include the entire shared memory block. This is frequently misinterpreted to be a memory leak; but it is no such thing, only a reporting artifact.

== Operational Questions ==

=== How do I SELECT only the first few rows of a query? A random row? ===

To retrieve only a few rows, if you know at the number of rows needed
at the time of the SELECT use LIMIT . If an index matches the ORDER BY
it is possible the entire query does not have to be executed. If you
don't know the number of rows at SELECT time, use a cursor and FETCH.

To SELECT a random row, use:
SELECT col
FROM tab
ORDER BY random()
LIMIT 1;

See also this [http://blog.rhodiumtoad.org.uk/2009/03/08/selecting-random-rows-from-a-table/ blog entry by Andrew Gierth]
that has more information on this topic.

=== How do I find out what tables, indexes, databases, and users are defined? How do I see the queries used by psql to display them? ===

Use the \dt command to see tables in psql. For a complete list of
commands inside psql you can use \?. Alternatively you can read the
source code for psql in file pgsql/src/bin/psql/describe.c, it
contains SQL commands that generate the output for psql's backslash
commands. You can also start psql with the -E option so it will print
out the queries it uses to execute the commands you give. PostgreSQL
also provides an SQL compliant INFORMATION SCHEMA interface you can
query to get information about the database.

There are also system tables beginning with pg_ that describe these
too.

Use psql -l will list all databases.

Also try the file pgsql/src/tutorial/syscat.source. It illustrates
many of the SELECTs needed to get information from the database system
tables.

=== How do you change a column's data type? ===

Changing the data type of a column can be done easily in 8.0 and later
with ALTER TABLE ALTER COLUMN TYPE.

In earlier releases, do this:
BEGIN;
ALTER TABLE tab ADD COLUMN new_col new_data_type;
UPDATE tab SET new_col = CAST(old_col AS new_data_type);
ALTER TABLE tab DROP COLUMN old_col;
COMMIT;

You might then want to do VACUUM FULL tab to reclaim the disk space
used by the expired rows.

=== What is the maximum size for a row, a table, and a database? ===

These are the limits:

Maximum size for a database? unlimited (32 TB databases exist)
Maximum size for a table? 32 TB
Maximum size for a row? 400 GB
Maximum size for a field? 1 GB
Maximum number of rows in a table? unlimited
Maximum number of columns in a table? 250-1600 depending on column types
Maximum number of indexes on a table? unlimited

Of course, these are not actually unlimited, but limited to available
disk space and memory/swap space. Performance may suffer when these
values get unusually large.

The maximum table size of 32 TB does not require large file support
from the operating system. Large tables are stored as multiple 1 GB
files so file system size limits are not important.

The maximum table size, row size, and maximum number of columns can be
quadrupled by increasing the default block size to 32k. The maximum
table size can also be increased using table partitioning.

One limitation is that indexes can not be created on columns longer
than about 2,000 characters. Fortunately, such indexes are rarely
needed. Uniqueness is best guaranteed by a function index of an MD5
hash of the long column, and full text indexing allows for searching
of words within the column.

=== How much database disk space is required to store data from a typical text file? ===

A PostgreSQL database may require up to five times the disk space to
store data from a text file.

As an example, consider a file of 100,000 lines with an integer and
text description on each line. Suppose the text string averages
twenty bytes in length. The flat file would be 2.8 MB. The size of the
PostgreSQL database file containing this data can be estimated as 5.2
MB:
24 bytes: each row header (approximate)
24 bytes: one int field and one text field
+ 4 bytes: pointer on page to tuple
----------------------------------------
52 bytes per row

The data page size in PostgreSQL is 8192 bytes (8 KB), so:

8192 bytes per page
------------------- = 158 rows per database page (rounded down)
52 bytes per row

100000 data rows
------------------ = 633 database pages (rounded up)
158 rows per page

633 database pages * 8192 bytes per page = 5,185,536 bytes (5.2 MB)

Indexes do not require as much overhead, but do contain the data that
is being indexed, so they can be large also.

NULLs are stored as bitmaps, so they use very little space.

Note that long values may be compressed transparently.

See also this presentation on the topic: [[Image:How_Long_Is_a_String.pdf]].

=== Why are my queries slow? Why don't they use my indexes? ===

Indexes are not used by every query. Indexes are used only if the
table is larger than a minimum size, and the query selects only a
small percentage of the rows in the table. This is because the random
disk access caused by an index scan can be slower than a straight read
through the table, or sequential scan.

To determine if an index should be used, PostgreSQL must have
statistics about the table. These statistics are collected using
VACUUM ANALYZE, or simply ANALYZE. Using statistics, the optimizer
knows how many rows are in the table, and can better determine if
indexes should be used. Statistics are also valuable in determining
optimal join order and join methods. Statistics collection should be
performed periodically as the contents of the table change.

Indexes are normally not used for ORDER BY or to perform joins. A
sequential scan followed by an explicit sort is usually faster than an
index scan of a large table. However, LIMIT combined with ORDER BY
often will use an index because only a small portion of the table is
returned.

If you believe the optimizer is incorrect in choosing a sequential
scan, use SET enable_seqscan TO 'off' and run query again to see if an
index scan is indeed faster.

When using wild-card operators such as LIKE or ~, indexes can only be
used in certain circumstances:

* The beginning of the search string must be anchored to the start of the string, i.e.
** LIKE patterns must not start with % or _.
** ~ (regular expression) patterns must start with ^.

* The search string can not start with a character class, e.g. [a-e].

* Case-insensitive searches such as ILIKE and ~* do not utilize indexes. Instead, use expression indexes, which are described in [[#How_do_I_perform_regular_expression_searches_and_case-insensitive_regular_expression_searches.3F_How_do_I_use_an_index_for_case-insensitive_searches.3F | section 4.8]].

* C locale must be used during initdb because sorting in a non-C locale often doesn't match the behavior of LIKE. You can create a special text_pattern_ops index that will work in such cases, but note it is only helpful for LIKE indexing.

It is also possible to use full text indexing for word searches.

The [[SlowQueryQuestions]] article contains some more tips and guidance.

=== How do I see how the query optimizer is evaluating my query? ===

This is done with the EXPLAIN command; see [[Using EXPLAIN]].

=== How do I change the sort ordering of textual data? ===

PostgreSQL sorts textual data according to the ordering that is defined by the current locale, which is selected during initdb.
(In 8.4 and up it will be possible to select a different locale when creating a new database.)
If you don't like the ordering then you need to use a different locale.
In particular, most locales other than "C" sort according to dictionary order, which largely ignores punctuation and spacing.
If that's not what you want then you need "C" locale.

=== How do I perform regular expression searches and case-insensitive regular expression searches? How do I use an index for case-insensitive searches? ===

The ~ operator does regular expression matching, and ~* does
case-insensitive regular expression matching. The case-insensitive
variant of LIKE is called ILIKE.

Case-insensitive equality comparisons are normally expressed as:
SELECT *
FROM tab
WHERE lower(col) = 'abc';

This will not use a standard index on "col". However, if you create an
expression index on "lower(col)", it will be used:
CREATE INDEX tabindex ON tab (lower(col));

If the above index is created as UNIQUE, then the column can store
upper and lowercase characters, but it cannot contain identical values that
differ only in case. To force a particular case to be stored in the
column, use a CHECK constraint or a trigger.

In PostgreSQL 8.4 and later, you can also use the contributed [http://www.postgresql.org/docs/8.4/static/citext.html CITEXT data type], which internally implements the "lower()" calls, so that you can effectively treat it as a fully case-insensitive data type. CITEXT is also [https://svn.kineticode.com/citext/trunk/ available for 8.3], and an earlier version that treats only ASCII characters case-insensitively on 8.2 and earlier is available on [http://pgfoundry.org/projects/citext/ pgFoundry].

=== In a query, how do I detect if a field is NULL? How do I concatenate possible NULLs? How can I sort on whether a field is NULL or not? ===

You can test the value with IS NULL or IS NOT NULL, like this:
SELECT *
FROM tab
WHERE col IS NULL;

Concatenating a NULL with something else produces another NULL.
If that's not what you want, you can replace the NULL(s) using
COALESCE(), like this:
<nowiki>SELECT COALESCE(col1, '') || COALESCE(col2, '')</nowiki>
FROM tab;

To sort by the NULL status, use an IS NULL or IS NOT NULL test
in your ORDER BY clause. Things that are true will sort higher than
things that are false, so the following will put NULL entries at the
front of the output:
SELECT *
FROM tab
ORDER BY (col IS NOT NULL), col;

In PostgreSQL 8.3 and up, you can also control sort ordering of NULLs
using the recently-standardized NULLS FIRST/NULLS LAST modifiers,
like this:
SELECT *
FROM tab
ORDER BY col NULLS FIRST;

=== What is the difference between the various character types? ===

{| border="1"
!Type
!Internal Name
!Notes
|-
|VARCHAR(n)
|varchar
|size specifies maximum length, no padding
|-
|CHAR(n)
|bpchar
|blank-padded to the specified fixed length
|-
|TEXT
|text
|no specific upper limit on length
|-
|BYTEA
|bytea
|variable-length byte array (null-byte safe)
|-
|"char" (with the quotes)
|char
|one byte
|}

You will see the internal name when examining system catalogs and in
some error messages.

The first four types above are "varlena" types (i.e., the field length
is explicitly stored on disk, followed by the data). Thus the actual
space used is slightly greater than the expected size. However, long
values are also subject to compression, so the space on disk might
also be less than expected.

VARCHAR(n) is best when storing variable-length strings if a specific
upper limit on the string length is required by the application.
TEXT is for strings of "unlimited" length (though all fields in PostgreSQL
are subject to a maximum value length of one gigabyte).

CHAR(n) is for storing strings that are all the same length. CHAR(n)
pads with blanks to the specified length, while VARCHAR(n) only stores
the characters supplied. BYTEA is for storing binary data,
particularly values that include zero bytes. All these types have similar
performance characteristics, except that the blank-padding involved
in CHAR(n) requires additional storage and some extra runtime.

The "char" type (the quotes are required to distinguish it from CHAR(n))
is a specialized datatype that can store exactly one byte. It is found in
the system catalogs but its use in user tables is generally discouraged.

=== How do I create a serial/auto-incrementing field? ===

PostgreSQL supports a SERIAL data type. Actually, this isn't quite
a real type. It's a shorthand for creating an integer column that
is fed from a sequence.

For example, this:
CREATE TABLE person (
id SERIAL,
name TEXT
);
is automatically translated into this:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INTEGER NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

The automatically created sequence is named ''table''_''serialcolumn''_seq,
where ''table'' and ''serialcolumn'' are the names of the table and SERIAL
column, respectively. See the CREATE SEQUENCE manual page for more
information about sequences.

There is also BIGSERIAL, which is like SERIAL except that the resulting
column is of type BIGINT instead of INTEGER. Use this type if you think
that you might need more than 2 billion serial values over the lifespan
of the table.

=== How do I get the value of a SERIAL insert? ===

The simplest way is to retrieve the assigned SERIAL value with
RETURNING. Using the example table in the previous question, it would look like this:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

You can also call nextval() and use that value in the INSERT, or call
currval() after the INSERT.

=== Doesn't currval() lead to a race condition with other users? ===

No. currval() returns the latest sequence value assigned by your session,
independently of what is happening in other sessions.

=== Why are there gaps in the numbering of my sequence/SERIAL column? Why aren't my sequence numbers reused on transaction abort? ===

To improve concurrency, sequence values are given out to running
transactions on-demand; the sequence object is not kept locked but is
immediately available for another transaction to get another sequence
value. This causes gaps in numbering from aborted transactions.

=== What is an OID? ===

If a table is created WITH OIDS, each row includes an OID column that is automatically filled in during INSERT.
OIDs are sequentially assigned 4-byte integers. Initially they are unique
across the entire installation. However, the OID counter wraps around at 4 billion,
and after that OIDs may be duplicated.

It is possible to prevent duplication of OIDs within a single table by
creating a unique index on the OID column (but note that the WITH OIDS
clause doesn't by itself create such an index).
The system checks the index to see if a newly
generated OID is already present, and if so generates a new OID and
repeats. This works well so long as no OID-containing table has
more than a small fraction of 4 billion rows.

PostgreSQL uses OIDs for object identifiers in the system catalogs,
where the size limit is unlikely to be a problem.

To uniquely number rows in user tables, it is best to use SERIAL
rather than an OID column, or BIGSERIAL if the table is expected to
have more than 2 billion entries over its lifespan.

=== What is a CTID? ===

CTIDs identify specific physical rows by their block and
offset positions within a table.
They are used by index entries to point to physical rows.
A logical row's CTID changes when it is updated, so the CTID
cannot be used as a long-term row identifier. But it is sometimes
useful to identify a row within a transaction when no competing
update is expected.

=== Why do I get the error "ERROR: Memory exhausted in AllocSetAlloc()"? ===

You probably have run out of virtual memory on your system, or your
kernel has a low limit for certain resources. Try this before starting
the server:
ulimit -d 262144
limit datasize 256m

Depending on your shell, only one of these may succeed, but it will
set your process data segment limit much higher and perhaps allow the
query to complete. This command applies to the current process, and
all subprocesses created after the command is run. If you are having a
problem with the SQL client because the backend is returning too much
data, try it before starting the client.

=== How do I tell what PostgreSQL version I am running? ===

Run this query: SELECT version();

=== Is there a way to leave an audit trail of database operations? ===

There's nothing built-in, but it's not too difficult to build such
facilities yourself.

Simple example right in the official docs:
http://www.postgresql.org/docs/8.3/static/plpgsql-trigger.html#PLPGSQL-TRIGGER-AUDIT-EXAMPLE

Project targeting this feature: http://pgfoundry.org/projects/tablelog/

Background information and other sample implementations:
http://it.toolbox.com/blogs/database-soup/simple-data-auditing-19014
http://www.go4expert.com/forums/showthread.php?t=7252
http://www.alberton.info/postgresql_table_audit.html

=== How do I create a column that will default to the current time? ===

Use CURRENT_TIMESTAMP:
CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== How do I perform an outer join? ===

PostgreSQL supports outer joins using the SQL standard syntax. Here
are two examples:
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);

or
SELECT *
FROM t1 LEFT OUTER JOIN t2 USING (col);

These identical queries join t1.col to t2.col, and also return any
unjoined rows in t1 (those with no match in t2). A RIGHT join would
add unjoined rows of t2. A FULL join would return the matched rows
plus all unjoined rows from t1 and t2. The word OUTER is optional and
is assumed in LEFT, RIGHT, and FULL joins. Ordinary joins are called
INNER joins.

=== How do I perform queries using multiple databases? ===

There is no way to query a database other than the current one.
Because PostgreSQL loads database-specific system catalogs, it is
uncertain how a cross-database query should even behave.

contrib/dblink allows cross-database queries using function calls. Of
course, a client can also make simultaneous connections to different
databases and merge the results on the client side.

=== How do I return multiple rows or columns from a function? ===

It is easy using set-returning functions,
[[Return more than one row of data from PL/pgSQL functions]].

=== Why do I get "relation with OID ##### does not exist" errors when accessing temporary tables in PL/PgSQL functions? ===

In PostgreSQL versions < 8.3, PL/PgSQL caches function scripts, and an
unfortunate side effect is that if a PL/PgSQL function accesses a
temporary table, and that table is later dropped and recreated, and
the function called again, the function will fail because the cached
function contents still point to the old temporary table. The solution
is to use EXECUTE for temporary table access in PL/PgSQL. This will
cause the query to be reparsed every time.

This problem does not occur in PostgreSQL 8.3 and later.

=== What replication solutions are available? ===

Though "replication" is a single term, there are several technologies
for doing replication, with advantages and disadvantages for each.
Our documentation contains a good introduction to this topic at
http://www.postgresql.org/docs/8.3/static/high-availability.html and a
grid listing replication software and features is at
[[Replication, Clustering, and Connection Pooling]]

Master/slave replication allows a single master to receive read/write
queries, while slaves can only accept read/SELECT queries. The most
popular freely available master-slave PostgreSQL replication solution
is Slony-I.

Multi-master replication allows read/write queries to be sent to
multiple replicated computers. This capability also has a severe
impact on performance due to the need to synchronize changes between
servers. PGCluster is the most popular such solution freely available
for PostgreSQL.

There are also proprietary and hardware-based replication solutions
available supporting a variety of replication models.

=== Is possible to create a shared-storage postgresql server cluster? ===

PostgreSQL does not support clustering using [[Shared_Storage|shared storage]] on a SAN, SCSI backplane,
iSCSI volume, or other shared media. Such "RAC-style" clustering isn't supported.
Only replication-based clustering is currently supported.

See [[Replication, Clustering, and Connection Pooling]] information for details.

[[Shared_Storage|Shared-storage]] 'failover' is possible, but it is not safe to have more than one
postmaster running and accessing the data store at the same time. Heartbeat and
[http://en.wikipedia.org/wiki/STONITH STONITH] or some other hard-disconnect option are recommended.

=== Why are my table and column names not recognized in my query? Why is capitalization not preserved? ===

The most common cause of unrecognized names is the use of
double-quotes around table or column names during table creation. When
double-quotes are used, table and column names (called identifiers)
are stored case-sensitive, meaning you must use double-quotes when
referencing the names in a query. Some interfaces, like pgAdmin,
automatically double-quote identifiers during table creation. So, for
identifiers to be recognized, you must either:

* Avoid double-quoting identifiers when creating tables
* Use only lowercase characters in identifiers
* Double-quote identifiers when referencing them in queries

=== I lost the database password. What can I do to recover it? ===

You can't. However, you can reset it to something else. To do this, you

* edit pg_hba.conf to allow ''trust'' authorization temporarily
* Reload the config file (pg_ctl reload)
* Connect and issue ALTER ROLE / PASSWORD to set the new password
* edit pg_hba.conf again and restore the previous settings
* Reload the config file again

=== Does PostgreSQL have stored procedures? ===

PostgreSQL doesn't. However PostgreSQL have very powerful functions and user-defined functions capabilities that can do most things that other RDBMS stored routines (procedures and functions) can do and in many cases more.

These functions can be of different types and can be implemented in several programming languages.
(Refer to documentation for more details. [http://www.postgresql.org/docs/current/static/xfunc.html User-Defined Functions])

PostgreSQL functions can be invoked in many ways. If you want to invoke a function as you would call a stored procedure in other RDBMS (typically a function with side-effects but whose result you don't care for example because it returns void), one option would be to use [http://www.postgresql.org/docs/current/static/plpgsql.html PL/pgSQL Language] for your procedure and the [http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-NORESULT PERFORM] command. Example:
PERFORM theNameOfTheFunction(arg1, arg2);

Note that invoking instead:
SELECT theNameOfTheFunction(arg1, arg2);
would produce a result even if the function returns void (this result would be one row containing a void value).

[http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-NORESULT PERFORM] could thus be used to discard this unuseful result.

The main limitations on Pg's stored functions - as compared to true stored procedures - are:

* inability to return multiple result sets
* no support for autonomous transactions (<code>BEGIN</code>, <code>COMMIT</code> and <code>ROLLBACK</code> within a function)
* no support for the SQL-standard <code>CALL</code> syntax, though the ODBC and JDBC drivers will translate calls for you.

=== Why don't BEGIN, ROLLBACK and COMMIT work in stored procedures/functions? ===

PostgreSQL doesn't support autonomous transactions in its stored functions. Like all PostgreSQL queries, stored functions always run in a transaction and cannot operate outside a transaction.

If you need a stored procedure to manage transactions, you can look into the dblink interface or do the work from a client-side script instead. In some cases you can do what you need to using [http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING exception blocks in PL/PgSQL], because each BEGIN/EXCEPTION/END block creates a subtransaction.

=== Why is "SELECT count(*) FROM bigtable;" slow? ===

It can't be answered directly from an index. PostgreSQL has to check the visibility for each record, so it
forces a sequential scan of the entire table. If you want, you can keep track of the number of rows yourself with triggers, but beware that this will slow down write access to the table.

You can get an estimation. The reltuples column in [http://www.postgresql.org/docs/current/static/catalog-pg-class.html pg_class] contains the information from the latest [http://www.postgresql.org/docs/current/static/sql-analyze.html ANALYZE] of the table. On a large table this is often accurate to within a few thousandths of a percent, which is accurate enough for many purposes.

An "exact" count is often not exact for very long, anyway; due to [http://www.postgresql.org/docs/current/static/mvcc-intro.html MVCC] concurrency, the count will be accurate as of the moment the SELECT count(*) query (or, for stricter [http://www.postgresql.org/docs/current/static/transaction-iso.html transaction isolation] levels, its transaction) ''started'', and may well be out-of-date by the time the query completes. In a transaction mix where the table is being modified, two count(*) executions which return at the same moment might have different values, if a modifying transaction committed between their start times.

For more information, see [[Slow Counting]].

=== Why is my query much slower when run as a prepared query? ===

When PostgreSQL has the full query with all parameters known by planning time, it can use statistics in the table to find out if the values used in the query are very common or very uncommon in a column. This lets it change the way it fetches the data to be more efficient, as it knows to expect lots or very few results from a certain part of the query. For example, it might choose an sequential scan instead of doing an index scan if you search for 'active=y' and it knows that 99% of the records in the table have 'active=y', because in this case a sequential scan will be much faster.

In a prepared query, PostgreSQL doesn't have the value of all parameters when it's creating the plan. It has to try to pick a "safe" plan that should work fairly well no matter what value you supply as the parameter when you execute the prepared query. Unfortunately, this plan might not be very appropriate if the value you supply is vastly more common, or vastly less common, than is average for some randomly selected values in the table.

If you suspect this issue is affecting you, start by using the [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] command to compare the slow and fast queries. Look at the output of <code>EXPLAIN SELECT query...</code> and compare it to the result of <code>PREPARE query... ; EXPLAIN EXECUTE query...</code> to see if the plans are notably different. <code>EXPLAIN ANALYZE</code> may give you more information, such as row count estimates and counts.

Usually people having this problem are trying to use prepared queries as a security measure to prevent SQL injection, rather than as a performance tuning option for expensive-to-plan queries frequently executed with a variety of different parameters. Those people should consider using client-side prepared statements if their client interface (eg PgJDBC) supports it.

At present, PostgreSQL does not offer a way to request re-planning of a prepared statement using a particular set of parameter values; doing so somewhat defeats the purpose of server-side prepared statements. Running a statistics check to see if a particular parameter value is notably outside the norm and automatically re-planning in that case has been discussed, but not agreed upon or implemented as yet.

See [[Using_EXPLAIN]]. If you're going to ask for help on the mailing lists, please read the [[Guide to reporting problems]].

=== Why is my query much slower when run in a function than standalone? ===

See [[FAQ#Why is my query much slower when run as a prepared query?]]. Queries in PL/PgSQL functions are prepared and cached, so they execute in much the same way as if you'd <code>PREPARE</code>d then <code>EXECUTE</code>d the query yourself.

If you're having really severe issues with this that improving the table statistics or adjusting your query don't help with, you can work around it by forcing PL/PgSQL to re-prepare your query at every execution. To do this, use the <code>EXECUTE ... USING</code> statement in PL/PgSQL to supply your query as a textual string. Alternately, the [http://www.postgresql.org/docs/current/static/functions-string.html quote_literal or quote_nullable] functions may be used to escape parameters substituted into query text.

=== Why do my strings sort incorrectly? ===

First, make sure you are using the locale you want to be using. Use <code>SHOW lc_collate</code> to show the database-wide locale in effect. If you are using per-column collations, check those. If everything is how you want it, then read on.

PostgreSQL uses the C library's locale facilities for sorting strings. So if the sort order of the strings is not what you expect, the issue is likely in the C library. You can verify the C library's idea of sorting using the <code>sort</code> utility on a text file, e.g.,

LC_COLLATE=xx_YY.utf8 sort testfile.txt

If this results in the same order that PostgreSQL gives you, then the problem is outside of PostgreSQL.

PostgreSQL deviates from the libc behavior in so far as it breaks ties by sorting strings in byte order. This should rarely make a
difference in practice, and is usually not the source of the problem when users complain about the sort order, but it could affect cases where, for example, combining and precombined Unicode characters are mixed.

If the problem is in the C library, you will have to take it up with your operating system maintainers. Note, however, that while actual bugs in locale definitions of C libraries have been known to exist, it is more likely that the C library is correct, where "correct" means it follows some recognized international or national standard. Possibly, you are expecting one of multiple equally valid interpretations of a language's sorting rules.

Common complaint patterns include:

* Spaces and special characters: The sorting algorithm normally works in multiple passes. First, all the letters are compared, ignoring spaces and punctuation. Then, spaces and punctuation are compared to break ties. (This is a simplification of what actually happens.) It's not possible to change this without changing the locale definitions themselves (and even then it's difficult). You might want to restructure your data slightly to avoid this problem. For example, if you are sorting a name field, you could split the field into first and last name fields, avoiding the space in between.

* Upper/lower case: Locales other than the C locale generally sort upper and lower case letters together. So the order will be something like a A b B c C ... instead of the A B C ... a b c ... that a sort based on ASCII byte values will give. That is correct.

* German locale: sort order of ä as a or ae. Both of these are valid (see http://de.wikipedia.org/wiki/Alphabetische_Sortierung), but most C libraries only provide the first one. Fixing this would require creating a custom locale. This is possible, but will take some work.

* It is not in ASCII/byte order. No, it's not, it's not supposed to be. ASCII is an encoding, not a sort order. If you want this, you can use the C locale, but then you use the ability to non-ASCII characters.

That said, if you are on Mac OS X or a BSD-family operating system, and you are using UTF-8, then give up. The locale definitions on
those operating systems are broken.

[[Category:FAQ]]

Todo

2012-03-22T18:57:59Z

Petere: Done: Add use of 'const' for variables in source tree

<div style="margin: 1ex 1em; float: right;">
__TOC__
</div>

This list contains '''all known PostgreSQL bugs and feature requests'''. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].

* {{TodoPending}} - marks ordinary, incomplete items
* {{TodoEasy}} - marks items that are easier to implement
* {{TodoDone}} - marks changes that are done, and will appear in the PostgreSQL 9.2 release.

For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the mailing list.</b>

<div style="padding: 1ex 4em;">
== Administration ==

{{TodoItem
|Allow administrators to cancel multi-statement idle transactions
|This allows locks to be released, but it is complex to report the cancellation back to the client.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php <nowiki>Cancelling idle in transaction state</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00441.php <nowiki>Re: Cancelling idle in transaction state</nowiki>]
}}

{{TodoItem
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]
}}

{{TodoItem
|Set proper permissions on non-system schemas during db creation
|Currently all schemas are owned by the super-user because they are copied from the template1 database. However, since all objects are inherited from the template database, it is not clear that setting schemas to the db owner is correct.}}

{{TodoItem
|Allow log_min_messages to be specified on a per-module basis
|This would allow administrators to see more detailed information from specific sections of the backend, e.g. checkpoints, autovacuum, etc. Another idea is to allow separate configuration files for each module, or allow arbitrary SET commands to be passed to them. See also [[Logging Brainstorm]].}}

{{TodoItem
|Simplify creation of partitioned tables
|This would allow creation of partitioned tables without requiring creation of triggers or rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. See also [[Table partitioning]]
}}

{{TodoItem
|Allow custom variables to appear in pg_settings()
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]
}}

{{TodoItem
|Have custom variables be transaction-safe
* {{MessageLink|4B577E9F.8000505@dunslane.net|Custom GUCs still a bit broken}}
}}

{{TodoItem
|Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]
}}

{{TodoItem
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]
}}

{{TodoItem
|Provide a way to query the log collector subprocess to determine the name of the currently active log file
* [http://archives.postgresql.org/pgsql-general/2008-11/msg00418.php <nowiki>Current log files when rotating?</nowiki>]
}}

{{TodoItem
|Allow simpler reporting of the unix domain socket directory and allow easier configuration of its default location
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01555.php
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01482.php
}}

{{TodoItem
|Allow custom daemons to be automatically stopped/started along with the postmaster
|This allows easier administration of daemons like user job schedulers or replication-related daemons.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01701.php <nowiki>Re: scheduler in core</nowiki>]
}}

{{TodoItem
|Improve logging of prepared transactions recovered during startup
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>"recovering prepared transaction" after server restart message</nowiki>]
}}

{{TodoItem
|Consider using POSIX shared memory to avoid System V shared memory kernel limits
* [http://archives.postgresql.org/message-id/4DFA2673.3010009@enterprisedb.com <nowiki>POSIX shared memory patch status</nowiki>]
}}

{{TodoItemDone
|Address problem where superusers are assumed to be members of all groups
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
}}

=== Configuration files ===
{{TodoSubsection}}

{{TodoItemEasy
|Change pg_ident.conf parsing to be the same as pg_hba.conf
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg02204.php
}}

{{TodoItem
|Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00764.php
}}

{{TodoItem
|Consider normalizing fractions in postgresql.conf, perhaps using '%'
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]
}}

{{TodoItem
|Allow Kerberos to disable stripping of realms so we can check the username@realm against multiple realms
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php <nowiki>krb_match_realm patch</nowiki>]
}}

{{TodoItem
|Improve LDAP authentication configuration options
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php <nowiki>Proposed Patch - LDAPS support for servers on port 636 w/o TLS</nowiki>]
}}

{{TodoItem
|Add external tool to auto-tune some postgresql.conf parameters
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php <nowiki>Simple postgresql.conf wizard</nowiki>]
}}

{{TodoItem
|Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php <nowiki>Re: Plans for 8.4</nowiki>]
}}

{{TodoItem
|Process pg_hba.conf keywords as case-insensitive
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00432.php <nowiki>More robust pg_hba.conf parsing/error logging</nowiki>]
}}

{{TodoItem
|Create utility to compute accurate random_page_cost value
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00162.php
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00362.php
}}

{{TodoItem
|Allow configuration files to be independently validated
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php
* http://archives.postgresql.org/message-id/12666.1310774573@sss.pgh.pa.us
}}

{{TodoItem
|Allow postgresql.conf settings to be accepted by backends even if some settings are invalid for those backends
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoItem
|Allow all backends to receive postgresql.conf setting changes at the same time
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoEndSubsection}}

=== Tablespaces ===
{{TodoSubsection}}

{{TodoItem
|Allow a database in tablespace t1 with tables created in tablespace t2 to be used as a template for a new database created with default tablespace t2
|Currently all objects in the default database tablespace must have default tablespace specifications. This is because new databases are created by copying directories. If you mix default tablespace tables and tablespace-specified tables in the same directory, creating a new database from such a mixed directory would create a new database with tables that had incorrect explicit tablespaces. To fix this would require modifying pg_class in the newly copied database, which we don't currently do.}}

{{TodoItem
|Allow reporting of which objects are in which tablespaces
|This item is difficult because a tablespace can contain objects from multiple databases. There is a server-side function that returns the databases which use a specific tablespace, so this requires a tool that will call that function and connect to each database to find the objects in each database for that tablespace.}}

{{TodoItem
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original}}

{{TodoItem
|Allow per-tablespace quotas}}

{{TodoItem
|Allow tablespaces on RAM-based partitions for unlogged tables
* http://archives.postgresql.org/pgsql-advocacy/2011-05/msg00033.php
}}

{{TodoItem
|Allow toast tables to be moved to a different tablespace
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00980.php
* {{messageLink|CAFEQCbH756DyyAPQ1ykh3+b+kE1-EhWRww1WO_x5v38C-uLnUg@mail.gmail.com|patch : Allow toast tables to be moved to a different tablespace}} (issues remain)
* [http://archives.postgresql.org/message-id/CAFEQCbEq07OopgE5xFYv2Q3eMq45hRSJkjCBO+kvpJq9NEVhow@mail.gmail.com Allow toast tables to be moved to a different tablespace]
}}

{{TodoEndSubsection}}

=== Statistics Collector ===
{{TodoSubsection}}

{{TodoItem
|Allow statistics last vacuum/analyze execution times to be displayed without requiring track_counts to be enabled
* [http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php <nowiki>row-level stats and last analyze time</nowiki>]
}}

{{TodoItem
|Clear table counters on TRUNCATE
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php <nowiki>Small TRUNCATE glitch</nowiki>]
}}

{{TodoEndSubsection}}

=== SSL ===
{{TodoSubsection}}

{{TodoItem
|Allow SSL authentication/encryption over unix domain sockets
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00924.php <nowiki>Re: Spoofing as the postmaster</nowiki>]
}}

{{TodoItem
|Allow SSL key file permission checks to be optionally disabled when sharing SSL keys with other applications
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php <nowiki>BUG #3809: SSL "unsafe" private key permissions bug</nowiki>]
}}

{{TodoItem
|Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart
|Unlike SSL CRT files, CRL (Certificate Revocation List) files are updated frequently
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00832.php <nowiki>Automatic CRL reload</nowiki>]
Alternatively or additionally supporting OCSP (online certificate security protocol) would provide real-time revocation discovery without reloading
}}

{{TodoItem
| Allow automatic selection of SSL client certificates from a certificate store
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]
}}

{{TodoItem
| Send the full certificate server chain to the client
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]
}}

{{TodoEndSubsection}}

=== Point-In-Time Recovery (PITR) ===
{{TodoSubsection}}

{{TodoItemEasy
|Create dump tool for write-ahead logs for use in determining transaction id for point-in-time recovery
|This is useful for checking PITR recovery.}}

{{TodoItem
|Allow archive_mode to be changed without server restart?
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php <nowiki>Enabling archive_mode without restart</nowiki>]
}}

{{TodoItem
|Consider avoiding WAL switching via archive_timeout if there has been no database activity
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01469.php <nowiki>archive_timeout behavior for no activity</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg00395.php <nowiki>Re: archive_timeout behavior for no activity</nowiki>]
}}

{{TodoEndSubsection}}

=== Standby server mode ===
{{TodoSubsection}}

{{TodoItem
| Allow pg_xlogfile_name() to be used in recovery mode
* [http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12@mail.gmail.com <nowiki>Streaming replication and pg_xlogfile_name()</nowiki>]
}}

{{TodoItem
| Prevent variables inherited from the server environment from begin used for making streaming replication connections.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01011.php <nowiki>Re: Parameter name standby_mode</nowiki>]
}}

{{TodoItemDone
| Allow hot file system backups on standby servers
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01727.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
}}

{{TodoItem
| Change walsender so that it applies per-role settings
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00642.php
}}

{{TodoItemDone
| Add more control over waiting for synchronous commit
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01611.php
}}

{{TodoItem
| Restructure configuration parameters for standby mode
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01820.php
}}

{{TodoItem
| Allow time-delayed application of logs on the standby
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00992.php
}}
{{TodoItem
| Add -X parameter to pg_basebackup to specify a different directory for px_xlog, like initdb
}}

{{TodoEndSubsection}}

== Data Types ==

{{TodoItem
|Fix data types where equality comparison is not intuitive, e.g. box
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01643.php
}}

{{TodoItem
|Add support for public SYNONYMs
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php
* http://archives.postgresql.org/pgsql-general/2010-12/msg00139.php
}}

{{TodoItem
|Add support for SQL-standard GENERATED/IDENTITY columns
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]
}}

{{TodoItem
|Consider placing all sequences in a single table, or create a system view
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2012-02/msg00258.php Removing special case OID generation]
}}

{{TodoItem
|Consider a special data type for regular expressions
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]
}}

{{TodoItem
|Reduce BIT data type overhead using short varlena headers
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php <nowiki>storage size of "bit" data type..</nowiki>]
}}

{{TodoItem
|Allow renaming and deleting enumerated values from an existing enumerated data type
}}

{{TodoItem
|Support scoped IPv6 addresses in the inet type
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php <nowiki>strange problem with ip6</nowiki>]
}}

{{TodoItemDone
|Add a JSON (JavaScript Object Notation) data type
|This would behave similar to the XML data type, which is stored as text, but allows element lookup and conversion functions.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01494.php <nowiki>PATCH: Add hstore_to_json()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg00001.php <nowiki>Re: PATCH: Add hstore_to_json()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg01092.php <nowiki>Proposal: Add JSON support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00057.php <nowiki>Re: Proposal: Add JSON support</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00481.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01694.php
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg00219.php
}}

{{TodoItem
|Considering improving performance of computing CHAR() value lengths
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00900.php <nowiki>char() overhead on read-only workloads not so insignifcant as the docs claim it is...</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01787.php <nowiki>Re: [PATCH] backend: compare word-at-a-time in bcTruelen</nowiki>]
}}

{{TodoItem
|Add overlaps geometric operators that ignore point overlaps
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00861.php
}}

{{TodoItem
| Add IMMUTABLE column attribute
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00623.php
}}

=== Domains ===
{{TodoSubsection}}

{{TodoItem
|Allow functions defined as casts to domains to be called during casting
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]
}}

{{TodoItem
|Allow values to be cast to domain types
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00812.php
}}

{{TodoItem
|Make domains work better with polymorphic functions
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]
}}

{{TodoEndSubsection}}

=== Dates and Times ===
{{TodoSubsection}}

{{TodoItem
|Allow infinite intervals just like infinite timestamps
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00076.php
}}

{{TodoItem
|Determine how to represent date/time field extraction on infinite timestamps
* [http://archives.postgresql.org/message-id/CA+mi_8bda-Fnev9iXeUbnqhVaCWzbYhHkWoxPQfBca9eDPpRMw@mail.gmail.com extract(epoch from infinity) is not 0]
* [http://archives.postgresql.org/message-id/CADAkt-icuESH16uLOCXbR-dKpcvwtUJE4JWXnkdAjAAwP6j12g@mail.gmail.com converting between infinity timestamp and float8]
}}

{{TodoItem
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules.
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]
}}

{{TodoItem
|Have timestamp subtraction not call justify_hours()?
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]
}}

{{TodoItem
|Improve TIMESTAMP WITH TIME ZONE subtraction to be DST-aware
|Currently subtracting one date from another that crosses a daylight savings time adjustment can return '1 day 1 hour', but adding that back to the first date returns a time one hour in the future. This is caused by the adjustment of '25 hours' to '1 day 1 hour', and '1 day' is the same time the next day, even if daylight savings adjustments are involved.}}

{{TodoItem
|Fix interval display to support values exceeding 2^31 hours}}

{{TodoItem
|Add overflow checking to timestamp and interval arithmetic}}

{{TodoItem
|Add function to allow the creation of timestamps using parameters
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00232.php
}}

{{TodoEndSubsection}}

=== Arrays ===
{{TodoSubsection}}

{{TodoItem
|Add support for arrays of domains
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php <nowiki>Re: updated WIP: arrays of composites</nowiki>]
}}

{{TodoItem
|Allow single-byte header storage for array elements}}

{{TodoItem
|Add function to detect if an array is empty
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php <nowiki>Re: array_length()</nowiki>]
}}

{{TodoItem
|Improve handling of empty arrays
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php <nowiki>So what's an "empty" array anyway?</nowiki>]
}}

{{TodoItem
|Improve handling of NULLs in arrays
* [http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php <nowiki>BUG #4509: array_cat's null behaviour is inconsistent</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php
}}

{{TodoEndSubsection}}

=== Binary Data ===
{{TodoSubsection}}

{{TodoItem
|Improve vacuum of large objects, like contrib/vacuumlo?}}

{{TodoItem
|Auto-delete large objects when referencing row is deleted
|contrib/lo offers this functionality.}}

{{TodoItem
|Allow read/write into TOAST values like large objects
|Writing might require the TOAST column to be stored EXTERNAL.
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00049.php
}}

{{TodoItem
|Add API for 64-bit large object access
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00781.php <nowiki>64-bit API for large objects</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01790.php
}}

{{TodoEndSubsection}}

=== MONEY Data Type ===
{{TodoSubsection}}

{{TodoItem
|Add locale-aware MONEY type, and support multiple currencies
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]
}}

{{TodoItem
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}

{{TodoEndSubsection}}

=== Text Search ===
{{TodoSubsection}}

{{TodoItem
|Allow dictionaries to change the token that is passed on to later dictionaries
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]
}}

{{TodoItem
|Consider a function-based API for '@@' searches
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Simplifying Text Search</nowiki>]
}}

{{TodoItem
|Improve text search error messages
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php <nowiki>Re: Poorly designed tsearch NOTICEs</nowiki>]
}}

{{TodoItem
|Consider changing error to warning for strings larger than one megabyte
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00062.php <nowiki>Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
}}

{{TodoItem
|tsearch and tsdicts regression tests fail in Turkish locale on glibc
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]
}}

{{TodoItem
|tsquery negator operator treated as part of lexeme
* [http://archives.postgresql.org/pgsql-bugs/2009-06/msg00346.php BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation]
}}

{{TodoItem
|Improve handling of dash and plus signs in email address user names, and perhaps improve URL parsing
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00772.php
* [http://archives.postgresql.org/message-id/E1Ri8il-0008Ct-9p@wrigleys.postgresql.org tsearch does not recognize all valid emails]
}}

{{TodoItem
|Improve default parser, to more easily allow adding new tokens
* http://archives.postgresql.org/message-id/23485.1297727826@sss.pgh.pa.us
}}

{{TodoItem
|Add additional support functions
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00319.php
}}

{{TodoEndSubsection}}

=== XML ===
{{TodoSubsection}}

{{TodoItem
|Allow XML arrays to be cast to other data types
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
}}

{{TodoItem
|Add XML Schema validation and xmlvalidate functions (SQL:2008)}}

{{TodoItem
|Add xmlvalidatedtd variant to support validating against a DTD?}}

{{TodoItem
|Relax-NG validation; libxml2 supports this already}}

{{TodoItem
|Allow reliable XML operation non-UTF8 server encodings (xpath(), in particular, is known to not work)
* [http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php <nowiki>BUG #4622: xpath only work in utf-8 server encoding</nowiki>]
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}

{{TodoItem
|Add functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}

{{TodoItem
|Add XMLNAMESPACES support in XMLELEMENT and elsewhere}}

{{TodoItem
|Move XSLT from contrib/xml2 to a more reasonable location
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00539.php
}}

{{TodoItem
|Report errors returned by the XSLT library
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00562.php
}}

{{TodoItem
|Improve the XSLT parameter passing API
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00416.php
}}

{{TodoItem
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}

{{TodoItem
|Add pretty-printed XML output option
|Parse a document and serialize it back in some indented form. libxml2 might support this.}}

{{TodoItem
|Add XMLQUERY (from the SQL/XML standard)}}

{{TodoItem
|Allow XML sthredding
|In some cases shredding could be better option (if there is no need to keep XML docs entirely, e.g. if we have already developed tools that understand only relational data. This would be a separate module that implements annotated schema decomposition technique, similar to DB2 and SQL Server functionality.}}

{{TodoItem
|Fix Nested or repeated xpath() that apparently mess up namespaces [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00097.php] [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00144.php] [http://archives.postgresql.org/pgsql-general/2008-03/msg00295.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/message-id/004f01c90e91$138e9d10$3aabd730$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|XPath: Adding the <x> at the root causes problems [http://archives.postgresql.org/pgsql-bugs/2008-05/msg00184.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/pgsql-general/2008-07/msg00613.php]}}

{{TodoItem
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}

{{TodoItem
|xpath_table is pretty broken anyway [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php]}}

{{TodoItem
|better handling of XPath data types [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php] [http://archives.postgresql.org/message-id/004a01c90e90$4b986d90$e2c948b0$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|Improve handling of PIs and DTDs in xmlconcat() [http://archives.postgresql.org/message-id/200904211211.n3LCB09p008988@wwwmaster.postgresql.org]}}

{{TodoItem
|Restructure XML and /contrib/xml2 functionality
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02314.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00017.php
}}

{{TodoEndSubsection}}

== Functions ==

{{TodoItem
|Allow INET subnet comparisons using non-constants to be indexed}}

{{TodoItem
|Add an INET overlaps operator, for use by exclusion constraints
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00845.php
}}

{{TodoItem
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php <nowiki>RFC for adding typmods to functions</nowiki>]
}}

{{TodoItem
|Fix IS OF so it matches the ISO specification, and add documentation
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]
}}

{{TodoItem
|Implement Boyer-Moore searching in LIKE queries
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}
}}

{{TodoItem
|Prevent malicious functions from being executed with the permissions of unsuspecting users
|Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]
}}

{{TodoItem
|Reduce memory usage of aggregates in set returning functions
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]
}}

{{TodoItem
|Fix /contrib/ltree operator
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]
}}

{{TodoItem
|Fix /contrib/btree_gist's implementation of inet indexing
* [http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php <nowiki>BUG #5705: btree_gist: Index on inet changes query result</nowiki>]
}}

{{TodoItem
|<nowiki>Fix inconsistent precedence of =, >, and < compared to <>, >=, and <=</nowiki>
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php <nowiki>BUG #3822: Nonstandard precedence for comparison operators</nowiki>]
}}

{{TodoItem
|Fix regular expression bug when using complex back-references
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php <nowiki>BUG #3645: regular expression back references seem broken</nowiki>]
}}

{{TodoItem
|Have /contrib/dblink reuse unnamed connections
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php <nowiki>dblink un-named connection doesn't get re-used</nowiki>]
}}

{{TodoItem
|Improve formatting of pg_get_viewdef() output
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01648.php <nowiki>pg_get_viewdef formattiing</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01885.php <nowiki>Re: pretty print viewdefs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2011-12/msg00906.php reprise: pretty print viewdefs]
}}

{{TodoItem
|Add function to dump pg_depend information cleanly
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00226.php <nowiki>Elementary dependency look-up</nowiki>]
}}

{{TodoItemDone
|Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation
* [http://archives.postgresql.org/message-id/28488.1286461610@sss.pgh.pa.us pg_relation_size / could not open relation with OID #]
}}

=== Character Formatting ===

{{TodoSubsection}}
{{TodoItem
|Allow to_date() and to_timestamp() to accept localized month names}}

{{TodoItem
|Add missing parameter handling in to_char()
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]
}}

{{TodoItem
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]
}}

{{TodoItem
|Allow to_char() on interval values to accumulate the highest unit requested
|2= Some special format flag would be required to request such accumulation. Such functionality could also be added to EXTRACT. Prevent accumulation that crosses the month/day boundary because of the uneven number of days in a month.
* to_char(INTERVAL '1 hour 5 minutes', 'MI') => 65
* to_char(INTERVAL '43 hours 20 minutes', 'MI' ) => 2600
* to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') => 0:1:19:20
* to_char(INTERVAL '3 years 5 months','MM') => 41
}}

{{TodoItem
|Fix to_number() handling for values not matching the format string
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php <nowiki>Re: numeric_to_number() function skipping some digits</nowiki>]
}}

{{TodoEndSubsection}}

== Multi-Language Support ==

{{TodoItem
|Add NCHAR (as distinguished from ordinary varchar),}}

{{TodoItem
|Add a cares-about-collation column to pg_proc, so that unresolved-collation errors can be thrown at parse time
* [http://archives.postgresql.org/pgsql-hackers/2011-03/msg01520.php <nowiki>Open issues for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with text search configurations
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with to_char() and related functions
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Support collation-sensitive equality and hashing functions
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00472.php <nowiki> contrib/citext versus collations</nowiki>]
}}

{{TodoItem
|Add a LOCALE option to CREATE DATABASE, as a shorthand
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]
}}

{{TodoItem
|Support multiple simultaneous character sets, per SQL:2008}}

{{TodoItem
|Improve UTF8 combined character handling?}}

{{TodoItem
|Add octet_length_server() and octet_length_client()}}

{{TodoItem
|Make octet_length_client() the same as octet_length()?}}

{{TodoItem
|Fix problems with wrong runtime encoding conversion for NLS message files}}

{{TodoItem
|Add URL to more complete multi-byte regression tests
* [http://archives.postgresql.org/pgsql-hackers/2005-07/msg00272.php <nowiki>Multi-byte and client side character encoding tests for copy command..</nowiki>]
}}

{{TodoItem
|Fix contrib/fuzzystrmatch to work with multibyte encodings
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00138.php <nowiki> dmetaphone woes</nowiki>]
}}

{{TodoItem
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions
|Currently we preallocate memory based on worst-case usage.}}

{{TodoItem
|Add ability to use case-insensitive regular expressions on multi-byte characters
|Currently it works for UTF-8, but not other multi-byte encodings
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php <nowiki>Regexps vs. locale</nowiki>]
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}
}}

{{TodoItem
|Improve encoding of connection startup messages sent to the client
|Currently some authentication error messages are sent in the server encoding
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php <nowiki>encoding of PostgreSQL messages</nowiki>]
* [http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php <nowiki>Re: encoding of PostgreSQL messages</nowiki>]
}}

{{TodoItem
|More sensible support for Unicode combining characters, normal forms
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net
}}

== Views / Rules ==

{{TodoItem
|Automatically create rules on views so they are updateable, per SQL:2008
|We can only auto-create rules for simple views. For more complex cases users will still have to write rules manually.
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php <nowiki>Proposal for updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-08/msg00255.php <nowiki>Updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php <nowiki>Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle</nowiki>]
* http://wiki.postgresql.org/wiki/Updatable_views
}}

{{TodoItem
|Add the functionality of the WITH CHECK OPTION clause to CREATE VIEW}}

{{TodoItem
|Allow VIEW/RULE recompilation when the underlying tables change
|This is both difficult and controversial.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
* [http://archives.postgresql.org/message-id/CACk=U9NFSzWrEba8G5dZ=TZLy3_hx3QXGyCcKVWT=4iA1FjMuA@mail.gmail.com VIEW still referring to old name of field]
}}

{{TodoItem
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]
}}

{{TodoItem
|Add the ability to automatically create materialized views
|Right now materialized views require the user to create triggers on the main table to keep the summary table current. SQL syntax should be able to manage the triggers and summary table automatically. A more sophisticated implementation would automatically retrieve from the summary table when the main table is referenced, if possible. See [[Materialized Views]] for implementation details
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00479.php <nowiki>GSoC - proposal - Materialized Views in PostgreSQL</nowiki>]
}}

{{TodoItem
|Improve ability to modify views via ALTER TABLE
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]
}}

{{TodoItemDone
|Prevent low-cost functions from seeing unauthorized view rows
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg01346.php <nowiki>Using views for row-level access control is leaky</nowiki>]
}}

== SQL Commands ==

{{TodoItem
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT
* [http://dissipatedheat.com/2011/11/10/how-not-to-write-a-patch-for-postgresql/ How not to write this patch.]
}}

{{TodoItem
|Improve type determination of unknown (NULL or quoted literal) result columns for UNION/INTERSECT/EXCEPT
* [http://archives.postgresql.org/message-id/9799.1302719551@sss.pgh.pa.us <nowiki>UNION construct type cast gives poor error message</nowiki>]
}}

{{TodoItem
|Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00838.php <nowiki>WIP: grouping sets support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00466.php <nowiki>Implementation of GROUPING SETS (T431: Extended grouping capabilities)</nowiki>]
}}

{{TodoItem
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables</nowiki>]
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]
}}

{{TodoItem
|Add a GUC variable to warn about non-standard SQL usage in queries}}

{{TodoItem
|Add SQL-standard MERGE/REPLACE/UPSERT command
|MERGE is typically used to merge two tables. REPLACE or UPSERT command does UPDATE, or on failure, INSERT. See [[SQL MERGE]] for notes on the implementation details.
}}

{{TodoItem
|Add NOVICE output level for helpful messages
|For example, have it warn about unjoined tables. This could also control automatic sequence/index creation messages.
}}

{{TodoItem
|Allow NOTIFY in rules involving conditionals}}

{{TodoItem
|Allow EXPLAIN to identify tables that were skipped because of constraint_exclusion
}}

{{TodoItem
|Simplify dropping roles that have objects in several databases}}

{{TodoItem
|Allow the count returned by SELECT, etc to be represented as an int64 to allow a higher range of values}}

{{TodoItem
|Add support for WITH RECURSIVE ... CYCLE
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php <nowiki>WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows</nowiki>]}}

{{TodoItem
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}

{{TodoItem
|Allow DISTINCT to work in multiple-argument aggregate calls}}

{{TodoItem
|Add comments on system tables/columns using the information in catalogs.sgml
|Ideally the information would be pulled from the SGML file automatically.}}

{{TodoItem
|Prevent the specification of conflicting transaction read/write options
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php <nowiki>Re: SET TRANSACTION and SQL Standard</nowiki>]
}}

{{TodoItem
|Support LATERAL subqueries
|Lateral subqueries can reference columns of tables defined outside the subquery at the same level, i.e. ''laterally''.
For example, a LATERAL subquery in a FROM clause could reference tables defined in the same FROM clause.
Currently only the columns of tables defined ''above'' subqueries are recognized.
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php <nowiki>LATERAL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php <nowiki>Re: LATERAL</nowiki>]
* [http://archives.postgresql.org/message-id/4F5AA202.9020906@gmail.com lateral function as a subquery - WIP patch]
}}

{{TodoItem
|Prevent temporary tables created with ON COMMIT DELETE ROWS from repeatedly truncating the table on every commit if the table is already empty
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00842.php
* http://archives.postgresql.org/pgsql-performance/2010-03/msg00392.php
* http://archives.postgresql.org/pgsql-performance/2010-04/msg00046.php
}}

{{TodoItem
|Allow DELETE and UPDATE to be used with LIMIT and ORDER BY
* http://archives.postgresql.org/pgadmin-hackers/2010-04/msg00078.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01997.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00021.php
}}

{{TodoItemDone
|Improve caching of prepared query plans
}}

{{TodoItem
|Allow PREPARE of cursors}}

{{TodoItem
|Have DISCARD PLANS discard plans cached by functions
|DISCARD all should do the same.
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00431.php
}}

{{TodoItem
|Avoid multiple-evaluation of BETWEEN and IN arguments containing volatile expressions
* http://archives.postgresql.org/message-id/4D95B605.2020709@enterprisedb.com
}}

{{TodoItem
|Fix nested CASE-WHEN constructs
* http://archives.postgresql.org/message-id/4DDCEEB8.50602@enterprisedb.com
}}

=== CREATE ===
{{TodoSubsection}}

{{TodoItem
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}

{{TodoItem
|Have WITH CONSTRAINTS also create constraint indexes
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]
}}

{{TodoItem
|Move NOT NULL constraint information to pg_constraint
|Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. Another issue is that we should probably force NOT NULL to be propagated from parent tables to children, just as CHECK constraints are. (But then does dropping PRIMARY KEY affect children?)
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg01223.php
}}

{{TodoItem
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]
}}

{{TodoItem
|Add CREATE SCHEMA ... LIKE that copies a schema}}

{{TodoItem
|Fix CREATE OR REPLACE FUNCTION to not leave objects depending on the function in inconsistent state
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]
}}

{{TodoItem
|Allow temporary tables to exist as empty by default in all sessions
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php <nowiki>idea: global temp tables</nowiki>]
* [http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php <nowiki>Re: idea: global temp tables</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg01098.php <nowiki>global temporary tables</nowiki>]
}}

{{TodoItem
|Allow the creation of "distinct" types
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php <nowiki>Distinct types</nowiki>]
}}

{{TodoItem
|Consider analyzing temporary tables when they are first used in a query
|Autovacuum cannot analyze or vacuum temporary tables.
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php <nowiki>autovacuum and temp tables support</nowiki>]
}}

{{TodoItem
|Allow an unlogged table to be changed to logged
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00437.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00323.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00237.php
}}

{{TodoEndSubsection}}

=== UPDATE ===
{{TodoSubsection}}

{{TodoItem
|<nowiki>Allow UPDATE tab SET ROW (col, ...) = (SELECT...)</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg01308.php <nowiki>Re: [PATCHES] extension for sql update</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00865.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php <nowiki>Re: UPDATE using sub selects</nowiki>]
}}

{{TodoItem
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00016.php <nowiki>Re: Do we need a TODO? (was Re: Concurrently updating anupdatable view)</nowiki>]
}}

{{TodoItem
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows
|This is related to the previous item, which questions whether it even has the right semantics
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]
}}

{{TodoEndSubsection}}

=== ALTER ===
{{TodoSubsection}}

{{TodoItem
|Have ALTER TABLE RENAME of a SERIAL column rename the sequence
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
* [http://archives.postgresql.org/message-id/CADLWmXUV4LbLhMZL8rYMhCy72aZZLB5BSARPQVgoX0BrxA0FFg@mail.gmail.com renaming implicit sequences]
}}

{{TodoItem
|Have ALTER SEQUENCE RENAME rename the sequence name stored in the sequence table
* [http://archives.postgresql.org/pgsql-bugs/2007-09/msg00092.php <nowiki>BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00007.php <nowiki>Re: BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItemDone
|Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME or ALTER TABLE RENAME CONSTRAINT
* [http://archives.postgresql.org/pgsql-patches/2006-02/msg00168.php <nowiki>ALTER CONSTRAINT RENAME patch reverted</nowiki>]
}}

{{TodoItem
|Add ALTER DOMAIN to modify the underlying data type}}

{{TodoItem
|Allow ALTER TABLESPACE to move the tablespace to different directories}}

{{TodoItem
|Allow moving system tables to other tablespaces, where possible
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}

{{TodoItem
|Have ALTER INDEX update the name of a constraint using that index}}

{{TodoItem
|Allow column display reordering by recording a display, storage, and permanent id for every column?
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php <nowiki>Column reordering in pg_dump</nowiki>]
* http://archives.postgresql.org/message-id/1324412114-sup-9608@alvh.no-ip.org
}}

{{TodoItem
|Allow deactivating (and reactivating) indexes via ALTER TABLE
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01191.php
}}

{{TodoItem
|Add ALTER OPERATOR ... RENAME
|needs to consider effects of changing operator precedence
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]
}}

{{TodoItem
|Add ALTER TABLE ... RENAME RULE
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]
}}

{{TodoEndSubsection}}

=== CLUSTER ===
{{TodoSubsection}}

{{TodoItem
|Automatically maintain clustering on a table
|This might require some background daemon to maintain clustering during periods of low usage. It might also require tables to be only partially filled for easier reorganization. Another idea would be to create a merged heap/index data file so an index lookup would automatically access the heap data too. A third idea would be to store heap rows in hashed groups, perhaps using a user-supplied hash function.
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]
* http://community.enterprisedb.com/git/
* [http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php <nowiki>Re: maintain_cluster_order_v5.patch</nowiki>]
}}

{{TodoEndSubsection}}

=== COPY ===
{{TodoSubsection}}

{{TodoItem
|Allow COPY to report error lines and continue
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure.
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]
}}

{{TodoItem
|Allow COPY FROM to create index entries in bulk
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]
}}

{{TodoItem
|Allow COPY in CSV mode to control whether a quoted zero-length string is treated as NULL
|Currently this is always treated as a zero-length string, which generates an error when loading into an integer column
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php <nowiki>Re: [PATCHES] allow CSV quote in NULL</nowiki>]
}}

{{TodoItem
|Improve COPY performance
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01882.php
}}

{{TodoItem
|Allow COPY to report errors sooner
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]
}}

{{TodoItem
|Allow COPY to handle other number formats
|E.g. the German notation. Best would be something like WITH DECIMAL ','.
}}

{{TodoItem
|Allow a stalled COPY to exit if the backend is terminated
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00067.php <nowiki>Re: possible bug not in open items</nowiki>]
}}

{{TodoEndSubsection}}

=== GRANT/REVOKE ===
{{TodoSubsection}}

{{TodoItem
|Allow SERIAL sequences to inherit permissions from the base table?}}

{{TodoItem
|Allow dropping of a role that has connection rights
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php <nowiki>DROP ROLE dependency tracking ...</nowiki>]
}}
{{TodoEndSubsection}}

=== DECLARE CURSOR ===
{{TodoSubsection}}

{{TodoItem
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}

{{TodoItem
|Provide some guarantees about the behavior of cursors that invoke volatile functions
* [http://archives.postgresql.org/message-id/20997.1244563664@sss.pgh.pa.us Re: Cursor with hold emits the same row more than once across commits in 8.3.7]
}}

{{TodoEndSubsection}}

=== INSERT ===
{{TodoSubsection}}

{{TodoItem
|Allow INSERT/UPDATE of the system-generated oid value for a row}}

{{TodoItem
|In rules, allow VALUES() to contain a mixture of 'old' and 'new' references}}

{{TodoEndSubsection}}

=== SHOW/SET ===
{{TodoSubsection}}

{{TodoItem
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}

{{TodoItem
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count
* [http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php <nowiki>Re: [ADMIN] shared_buffers and shmmax</nowiki>]
}}

{{TodoEndSubsection}}

=== ANALYZE ===
{{TodoSubsection}}

{{TodoItem
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}

{{TodoItem
|Have EXPLAIN ANALYZE report rows as floating-point numbers
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg01363.php <nowiki>explain analyze rows=%.0f</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00108.php <nowiki>Re: explain analyze rows=%.0f</nowiki>]
}}

{{TodoItem
|Improve how ANALYZE computes in-doubt tuples
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]
}}

{{TodoEndSubsection}}

=== Window Functions ===
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.
{{TodoSubsection}}
{{TodoItem
|Support creation of user-defined window functions
|We have the ability to create new window functions written in C. Is it
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}

{{TodoItem
|Implement full support for window framing clauses
|In addition to done clauses described in the [http://developer.postgresql.org/pgdocs/postgres/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS latest doc], these clauses are not implemented yet.
* RANGE BETWEEN ... PRECEDING/FOLLOWING
* EXCLUDE
}}

{{TodoItem
|Investigate tuplestore performance issues
|The tuplestore_in_memory() thing is just a band-aid, we ought to try to solve it properly. tuplestore_advance seems like a weak spot as well.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php <nowiki>tuplestore potential performance problem</nowiki>]
}}

{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}

{{TodoItem
|Teach planner to evaluate multiple windows in the optimal order
|Currently windows are always evaluated in the query-specified order.
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64
}}

{{TodoItem
|Implement DISTINCT clause in window aggregates
|Some proprietary RDBMSs have implemented it already, so it helps with porting from those.}}

{{TodoEndSubsection}}

== Integrity Constraints ==
=== Keys ===

{{TodoSubsection}}

{{TodoItem
|Improve deferrable unique constraints for cases with many conflicts
|The current implementation fires a trigger for each potentially conflicting row. This might not scale well for an update that changes many key values at once.
}}

{{TodoEndSubsection}}

=== Referential Integrity ===
{{TodoSubsection}}

{{TodoItem
|Add MATCH PARTIAL referential integrity}}

{{TodoItem
|Change foreign key constraint for array -> element to mean element in array?
* [http://archives.postgresql.org/pgsql-hackers/2010-10/msg01814.php <nowiki>foreign keys for array/period contains relationships</nowiki>]
}}

{{TodoItem
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]
}}

{{TodoItem
|Optimize referential integrity checks
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php <nowiki>Can't ri_KeysEqual() consider two nulls as equal?</nowiki>]
}}

{{TodoEndSubsection}}

=== Check Constraints ===
{{TodoSubsection}}

{{TodoItem
|Run check constraints only when affected columns are changed
* http://archives.postgresql.org/message-id/1326055327.15293.13.camel@vanquo.pezone.net
}}

{{TodoEndSubsection}}

== Server-Side Languages ==

{{TodoItem
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}

{{TodoItem
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}

{{TodoItem
|Add more fine-grained specification of functions taking arbitrary data types
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php <nowiki>RfD: more powerful "any" types</nowiki>]
}}

{{TodoItem
|Implement stored procedures
|This might involve the control of transaction state and the return of multiple result sets
* [http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php <nowiki>PL/pgSQL stored procedure returning multiple result sets (SELECTs)?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php
* [http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php <nowiki>Gathering specs and discussion on feature (post 9.1)</nowiki>]
}}

{{TodoItem
|Allow holdable cursors in SPI}}

{{TodoItemEasy
|Add SPI_gettypmod() to return a field's typemod from a TupleDesc
* http://archives.postgresql.org/pgsql-hackers/2005-11/msg00250.php
}}

=== SQL-Language Functions ===
{{TodoSubsection}}

{{TodoItemDone
|Allow SQL-language functions to reference parameters by parameter name
|Currently SQL-language functions can only refer to dollar parameters, e.g. $1
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01479.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01519.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00221.php
}}

{{TodoItem
|Rethink query plan caching and timing of parse analysis within SQL-language functions
|They should work more like plpgsql functions do ...
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00078.php <nowiki>Re: BUG #6019: invalid cached plan on inherited table</nowiki>]
}}

{{TodoEndSubsection}}

=== PL/pgSQL ===
{{TodoSubsection}}

{{TodoItem
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}

{{TodoItem
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki>
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
}}

{{TodoItem
|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.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]
}}

{{TodoItem
|Consider keeping separate cached copies when search_path changes
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]
}}

{{TodoItem
|Improve handling of NULL row values vs. NULL rows
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php <nowiki>Null row vs. row of nulls in plpgsql</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01973.php
}}

{{TodoItem
|Improve PERFORM handling of WITH queries or document limitation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00309.php
}}

{{TodoEndSubsection}}

=== PL/Perl ===
{{TodoSubsection}}

{{TodoItem
|Allow regex operations in plperl using UTF8 characters in non-UTF8 encoded databases}}

{{TodoEndSubsection}}

=== PL/Python ===
{{TodoSubsection}}

{{TodoItem
|Develop a trusted variant of PL/Python.}}

{{TodoItem
|Create a new restricted execution class that will allow passing function arguments in as locals. Passing them as globals means functions cannot be called recursively.
* [http://archives.postgresql.org/pgsql-hackers/2011-02/msg01468.php <nowiki>Re: pl/python do not delete function arguments</nowiki>]
}}

{{TodoItem
|Add a DB-API compliant interface on top of the SPI interface
* http://petereisentraut.blogspot.com/2011/11/plpydbapi-db-api-for-plpython.html
}}

{{TodoItem
|For functions returning a setof record with a composite type, cache the I/O functions for the composite type
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02007.php
}}

{{TodoItem
|Fix loss of information during conversion of numeric type to Python float}}

{{TodoEndSubsection}}

=== PL/Tcl ===
{{TodoSubsection}}

{{TodoItem
|Add table function support}}

{{TodoItem
|Check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, and SPI calls.}}

{{TodoEndSubsection}}

== Clients ==

{{TodoItem
|Add a function like pg_get_indexdef() that report more detailed index information
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00166.php <nowiki>BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)</nowiki>]
}}

{{TodoItem
|Split out pg_resetxlog output into pre- and post-sections
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php
}}

=== pg_ctl ===
{{TodoSubsection}}

{{TodoItemDone
|Allow pg_ctl to work properly with configuration files located outside the PGDATA directory
|pg_ctl can not read the pid file because it isn't located in the config directory but in the PGDATA directory. The solution is to allow pg_ctl to read and understand postgresql.conf to find the data_directory value.
* [http://archives.postgresql.org/pgsql-bugs/2009-10/msg00024.php <nowiki>BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory</nowiki>]
}}

{{TodoItem
|Modify pg_ctl behavior and exit codes to make it easier to write an LSB conforming init script
|It may be desirable to condition some of the changes on a command-line switch, to avoid breaking existing scripts. A Linux shell (sh) script is referenced which has been tested and seems to provide a high degree of conformance in multiple environments. Study of this script might suggest areas where pg_ctl could be modified to make writing an LSB conforming script easier; however, some aspects of that script would be unnecessary with other suggested changes to pg_ctl, and discussion on the lists did not reach consensus on support for all aspects of this script. Further discussion of particular changes is needed before beginning any work.
* [[Lsb_conforming_init_script|LSB conforming init script]]
These threads should be studied for other ideas on improvements:
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01390.php <nowiki>We should Axe /contrib/start-scripts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01843.php <nowiki>Linux LSB init script</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00008.php <nowiki>Re: Linux LSB init script</nowiki>]
}}

{{TodoItem
|Improve pg_ctl's detection of running postmasters
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00000.php
* http://archives.postgresql.org/pgsql-committers/2011-06/msg00001.php
}}

{{TodoEndSubsection}}

=== psql ===
{{TodoSubsection}}

{{TodoItem
|Have psql \ds show all sequences and their settings
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00916.php <nowiki>Re: TODO item: Have psql show current values for a sequence</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00401.php <nowiki>Quick patch: Display sequence owner</nowiki>]
}}

{{TodoItemDone
|Have \d on a sequence indicate if the sequence is owned by a table}}

{{TodoItem
|Move psql backslash database information into the backend, use mnemonic commands?
|This would allow non-psql clients to pull the same information out of the database as psql.
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]
}}

{{TodoItem
|Make psql's \d commands more consistent in their handling of schemas
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php <nowiki>Re: psql and schemas</nowiki>]
}}

{{TodoItem
|Make psql's \d commands distinguish default privileges from no privileges
|ACL displays were visibly different for the two cases before we "improved" them by using array_to_string.
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00082.php <nowiki>BUG #6021: There is no difference between default and empty access privileges with \dp</nowiki>]
}}

{{TodoItem
|Consistently display privilege information for all objects in psql}}

{{TodoItemDone
|Add "auto" expanded mode that outputs in expanded format if "wrapped" mode can't wrap the output to the screen width
|Consider using auto-expanded mode for backslash commands like \df+.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00417.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01638.php
}}

{{TodoItem
|Prevent tab completion of SET TRANSACTION from querying the database and therefore preventing the transaction isolation level from being set.
|Currently SET <tab> causes a database lookup to check all supported session variables. This query causes problems because setting the transaction isolation level must be the first statement of a transaction.}}

{{TodoItemEasy
|\s without arguments (display history) fails with libedit, doesn't use pager either
* [http://archives.postgresql.org/pgsql-bugs/2011-06/msg00114.php <nowiki> psql \s not working - OS X</nowiki>]
}}

{{TodoItem
|Add a \set variable to control whether \s displays line numbers
|Another option is to add \# which lists line numbers, and allows command execution.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]
}}

{{TodoItem
|Include the symbolic SQLSTATE name in verbose error reports
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]
}}

{{TodoItem
|Add prompt escape to display the client and server versions
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00310.php <nowiki>WIP patch for TODO Item: Add prompt escape to display the client and server versions</nowiki>]
}}

{{TodoItem
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.
|Currently, "wrapped" format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}

{{TodoItem
|Support the ReST table output format
|Details about the ReST format: http://docutils.sourceforge.net/rst.html#reference-documentation
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg01007.php <nowiki>Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00518.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00609.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
}}

{{TodoItem
|Add option to print advice for people familiar with other databases
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php <nowiki>MySQL-ism help patch for psql</nowiki>]
}}

{{TodoItemDone
|\dd is missing comments for several types of objects
|Comments are not handled at all for some object types, and are handled by both \dd and the individual backslash command for others. Consider a system view like pg_comments to manage this mess.
* [http://archives.postgresql.org/pgsql-general/2009-09/msg00199.php <nowiki>comment on constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php <nowiki>pg_comments</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2011-05/msg00885.php <nowiki>patch: Allow \dd to show constraint comments</nowiki>]
}}

{{TodoItem
|Add ability to edit views with \ev
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00023.php <nowiki>Adding \ev view editor?</nowiki>]
}}

{{TodoItem
|Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php
}}

{{TodoItem
|Prevent psql from sending remaining single-line multi-statement queries after reconnecting
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php
}}

{{TodoItemEasy
|Add \i option to bring in the specified file as a quoted literal
|This would be useful for creating functions and other areas. Details still need to be worked out.
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00016.php
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00020.php
}}

{{TodoItem
|Consider having psql -c read .psqlrc, for consistency
|psql -f already reads .psqlrc
}}

{{TodoItem
|Allow processing of multiple -f (file) options
}}

{{TodoItem
|Improve line drawing characters
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00386.php
}}

{{TodoItem
|Consider improving the continuation prompt
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01772.php
}}

{{TodoEndSubsection}}

=== pg_dump / pg_restore ===
{{TodoSubsection}}

{{TodoItemEasy
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}

{{TodoItem
|Add pg_dumpall custom format dumps?
* [http://archives.postgresql.org/pgsql-general/2010-05/msg00509.php pg_dumpall custom format]
|}}

{{TodoItem
|Avoid using platform-dependent locale names in pg_dumpall output
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us
}}

{{TodoItem
|Allow selection of individual object(s) of all types, not just tables}}

{{TodoItem
|In a selective dump, allow dumping of an object and all its dependencies}}

{{TodoItem
|Add options like pg_restore -l and -L to pg_dump}}

{{TodoItem
|Add support for multiple pg_restore -t options, like pg_dump
|pg_restore's -t switch is less useful than pg_dump's in quite a few ways: no multiple switches, no pattern matching, no ability to pick up indexes and other dependent items for a selected table. It should be made to handle this switch just like pg_dump does.}}

{{TodoItem
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}

{{TodoItem
|Allow pg_dump --clean to drop roles that own objects or have privileges
|tgl says: if this is about pg_dumpall, it's done as of 8.4. If it's really about pg_dump, what does it mean? pg_dump has no business dropping roles.}}

{{TodoItemDone
|Allow pg_dump to utilize multiple CPUs and I/O channels by dumping multiple objects simultaneously
|The difficulty with this is getting multiple dump processes to produce a single dump output file. It also would require several sessions to share the same snapshot.
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00040.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02454.php
}}

{{TodoItem
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}

{{TodoItem
|Remove support for dumping from pre-7.3 servers
|In 7.3 and later, we can get accurate dependency information from the server. pg_dump still contains a lot of crufty code
to try to deal with the lack of dependency info in older servers, but the usefulness of maintaining that code grows small.}}

{{TodoItemDone
|Allow pre/data/post files when schema and data are dumped separately, for performance reasons
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00185.php <nowiki>Re: pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00821.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
}}

{{TodoItem
|Refactor handling of database attributes between pg_dump and pg_dumpall
|Currently only pg_dumpall emits database attributes, such as ALTER DATABASE SET commands and database-level GRANTs.
Many people wish that pg_dump would do that. One proposal is to let pg_dump issue such commands if the -C switch was used,
but it's unclear whether that will satisfy the demand.
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2010-05/msg00010.php summary of the issues]
}}

{{TodoItem
|Change pg_dump so that a comment on the dumped database is applied to the loaded database, even if the database has a different name.
|This will require new backend syntax, perhaps COMMENT ON CURRENT DATABASE. This is related to the previous item.}}

{{TodoItem
|Allow parallel restore of tar dumps
* [http://archives.postgresql.org/pgsql-hackers/2009-02/msg01154.php <nowiki>Re: parallel restore</nowiki>]
}}

{{TodoItemDone
|Allow pg_dumpall to output restorable ALTER USER/DATABASE SET settings
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00916.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00394.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02359.php
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg00489.php
}}

{{TodoEndSubsection}}

=== ecpg ===
{{TodoSubsection}}

{{TodoItem
|Docs
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}

{{TodoItem
|Solve cardinality > 1 for input descriptors / variables?}}

{{TodoItem
|Add a semantic check level, e.g. check if a table really exists}}

{{TodoItem
|fix handling of DB attributes that are arrays}}

{{TodoItem
|Fix nested C comments}}

{{TodoItemEasy
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}

{{TodoItem
|Make SET CONNECTION thread-aware, non-standard?}}

{{TodoItem
|Allow multidimensional arrays}}

{{TodoItem
|Implement COPY FROM STDIN}}

{{TodoItem
|Provide a way to specify size of a bytea parameter
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]
}}

{{TodoItemEasy
|Fix small memory leaks in ecpg
|Memory leaks in a short running application like ecpg are not really a problem, but make debugging more complicated}}

{{TodoItem
|Allow reuse of cursor name variables
* [http://archives.postgresql.org/message-id/20100329113435.GA3430@feivel.credativ.lan <nowiki>Problems with variable cursorname in ecpg</nowiki>]
}}

{{TodoEndSubsection}}

=== libpq ===
{{TodoSubsection}}

{{TodoItem
|Prevent PQfnumber() from lowercasing unquoted column names
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}

{{TodoItem
|Allow statement results to be automatically batched to the client
|Currently all statement results are transferred to the libpq client before libpq makes the results available to the application. This feature would allow the application to make use of the first result rows while the rest are transferred, or held on the server waiting for them to be requested by libpq. One complexity is that a statement like SELECT 1/col could error out mid-way through the result set.}}

{{TodoItem
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]
}}

{{TodoItem
|Add PQexecf() that allows complex parameter substitution
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]
}}

{{TodoItem
|Add SQLSTATE and severity to errors generated within libpq itself
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01425.php
}}

{{TodoItem
|Add support for interface/ipaddress binding to libpq
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php <nowiki>SR/libpq - outbound interface/ipaddress binding</nowiki>]
}}

{{TodoEndSubsection}}

== Triggers ==

{{TodoItem
|Improve storage of deferred trigger queue
|Right now all deferred trigger information is stored in backend memory. This could exhaust memory for very large trigger queues. This item involves dumping large queues into files, or doing some kind of join to process all the triggers, some bulk operation, or a bitmap.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php <nowiki>Scaling up deferred unique checks and the after trigger queue</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00023.php
}}

{{TodoItem
|Allow triggers to be disabled in only the current session.
|This is currently possible by starting a multi-statement transaction, modifying the system tables, performing the desired SQL, restoring the system tables, and committing the transaction. ALTER TABLE ... TRIGGER requires a table lock so it is not ideal for this usage.}}

{{TodoItem
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}

{{TodoItem
|Allow statement-level triggers to access modified rows}}

{{TodoItem
|When statement-level triggers are defined on a parent table, have them fire only on the parent table, and fire child table triggers only where appropriate
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php <nowiki>Statement-level triggers and inheritance</nowiki>]
}}

{{TodoItem
|Allow AFTER triggers on system tables
|System tables are modified in many places in the backend without going through the executor and therefore not causing triggers to fire. To complete this item, the functions that modify system tables will have to fire triggers.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01665.php
* http://wiki.postgresql.org/wiki/DDL_Triggers
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg00022.php
}}

{{TodoItem
|Tighten trigger permission checks
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]
}}

{{TodoItem
|Allow BEFORE INSERT triggers on views
* [http://archives.postgresql.org/pgsql-general/2007-02/msg01466.php <nowiki>Re: Why can't I put a BEFORE EACH ROW trigger on a view?</nowiki>]
}}

{{TodoItem
|Add database and transaction-level triggers
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]
}}

{{TodoItem
|Reduce locking requirements for creating a trigger
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php <nowiki>Re: Change lock requirements for adding a trigger</nowiki>]
}}

{{TodoItem
|Avoid requirement for "AFTER" trigger functions to return a value
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02384.php
}}

{{TodoItem
|Allow creation of inline triggers
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00708.php
}}

== Inheritance ==

{{TodoItem
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys
* [http://archives.postgresql.org/pgsql-hackers/2010-05/msg00285.php <nowiki>Partitioning/inherited tables vs FKs</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00039.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00305.php
}}

{{TodoItem
|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.}}

{{TodoItem
|Determine whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY). If yes, implement it.}}

{{TodoItem
|ALTER TABLE variants sometimes support recursion and sometimes not, but this is poorly/not documented, and the ONLY marker would then be silently ignored. Clarify the documentation, and reject ONLY if it is not supported.}}

== Indexes ==

{{TodoItem
|Prevent index uniqueness checks when UPDATE does not modify the column
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.
However, HOT already short-circuits this in common cases, so more work might not be helpful.}}

{{TodoItem
|Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes
|Such indexes could be more compact if there are only a few distinct values. Such indexes can also be compressed. Keeping such indexes updated can be costly.
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php <nowiki>Bitmap Indexes: request for feedback</nowiki>]
* http://archives.postgresql.org/message-id/800923.27831.qm@web29010.mail.ird.yahoo.com
}}

{{TodoItem
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02179.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00459.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02054.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01731.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00894.php
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00679.php
}}

{{TodoItem
|Consider having a larger statistics target for indexed columns and expression indexes.
}}

{{TodoItem
|Consider smaller indexes that record a range of values per heap page, rather than having one index entry for every heap row
|This is useful if the heap is clustered by the indexed values.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00341.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01264.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00465.php <nowiki>Grouped Index Tuples / Clustered Indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php <nowiki>Bitmapscan changes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php <nowiki>Re: GIT patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php <nowiki>Re: Index Tuple Compression Approach?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php <nowiki>Re: Index AM change proposals, redux</nowiki>]
}}

{{TodoItem
|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.
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]
}}

{{TodoItem
|Allow multiple indexes to be created concurrently, ideally via a single heap scan
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00093.php
}}

{{TodoItem
|Consider sorting entries before inserting into btree index
* [http://archives.postgresql.org/pgsql-general/2008-01/msg01010.php <nowiki>Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?</nowiki>]
}}

{{TodoItem
|Allow index scans to return matching index keys, not just the matching heap locations
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01657.php <nowiki>Re: Is this TODO item done?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01477.php <nowiki>Index-only quals</nowiki>]
}}

{{TodoItem
|Allow creation of an index that can do comparisons to test if a value is between two column values
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00757.php <nowiki>Proposal: temporal extension "period" data type</nowiki>]
}}

{{TodoItem
|Consider using "effective_io_concurrency" for index scans
* Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.
}}

{{TodoItem
|Fix problem with btree page splits during checkpoints
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00052.php
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00184.php
}}

=== GIST ===
{{TodoSubsection}}

{{TodoItem
|Add more GIST index support for geometric data types}}

{{TodoItem
|Allow GIST indexes to create certain complex index types, like digital trees (see Aoki)}}

{{TodoItem
|Fix performance issues in contrib/seg and contrib/cube GiST support
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00069.php <nowiki>Re: GiST index performance</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2009-06/msg00068.php <nowiki>GiST index performance</nowiki>]
}}

{{TodoEndSubsection}}

=== Hash ===
{{TodoSubsection}}

{{TodoItem
|Add UNIQUE capability to hash indexes}}

{{TodoItem
|Add hash WAL logging for crash recovery
* http://archives.postgresql.org/pgsql-performance/2011-09/msg00196.php
}}

{{TodoItem
|Allow multi-column hash indexes}}

{{TodoEndSubsection}}

== Sorting ==

{{TodoItem
|Consider whether duplicate keys should be sorted by block/offset
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]
}}

{{TodoItem
|Consider being smarter about memory and external files used during sorts
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php <nowiki>Re: Sorting Improvements for 8.4</nowiki>]
}}

{{TodoItem
|Consider detoasting keys before sorting}}

{{TodoItem
|Allow sorts to use more available memory
* http://archives.postgresql.org/pgsql-hackers/2007-11/msg01026.php
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01123.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg01957.php
}}

== Fsync ==

{{TodoItem
|Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether fsync does anything
|Ideally this requires a separate test program like /contrib/pg_test_fsync that can be run at initdb time or optionally later.}}

{{TodoItem
|Consider sorting writes during checkpoint
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php <nowiki>Re: Sorting writes during checkpoint</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg02012.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00278.php
* [http://archives.postgresql.org/message-id/CA+TgmoaHu1zuNohoE=cEP0nSc+0wtuRSyEAj_Af2XhxU+ry6-w@mail.gmail.com checkpoint writeback via sync_file_range]
}}

== Cache Usage ==

{{TodoItemDone
|Speed up COUNT(*)
|We could use a fixed row count and a +/- count to follow MVCC visibility rules, or a single cached value could be used and invalidated if anyone modifies the table. Another idea is to get a count directly from a unique index, but for this to be faster than a sequential scan it must avoid access to the heap to obtain tuple visibility information. Note that the index-only scans feature is now implemented which now dramatically speeds up some COUNT(*) cases.
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItem
|Provide a way to calculate an "estimated COUNT(*)"
|Perhaps by using the optimizer's cardinality estimates or random sampling.
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php <nowiki>Re: Improving count(*)</nowiki>]
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItemDone
|Allow data to be pulled directly from indexes
|Currently indexes do not have enough tuple visibility information to allow data to be pulled from the index without also accessing the heap. The idea is to use the visibility map used for vacuum to avoid heap lookups on pages where all tuples are visible.
* [http://wiki.postgresql.org/wiki/Index-only_scans Index-Only Scans wiki]
}}

{{TodoItem
|Consider automatic caching of statements at various levels:
* Parsed query tree
* Query execute plan
* Query results

:
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]
}}

{{TodoItem
|Consider increasing internal areas (NUM_CLOG_BUFFERS) when shared buffers is increased
* [http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php <nowiki>Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php <nowiki>clog_buffers to 64 in 8.3?</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php <nowiki>CLOG Patch</nowiki>]
}}

{{TodoItem
|Consider decreasing the amount of memory used by PrivateRefCount
|
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php <nowiki>PrivateRefCount (for 8.3)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php <nowiki>Re: PrivateRefCount (for 8.3)</nowiki>]
}}

{{TodoItem
|Consider allowing higher priority queries to have referenced buffer cache pages stay in memory longer
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]
}}

== Vacuum ==

{{TodoItem
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]
}}

{{TodoItem
|Allow concurrent inserts to use recently created pages rather than creating new ones
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php
}}

{{TodoItem
|Consider having single-page pruning update the visibility map
* <nowiki>https://commitfest.postgresql.org/action/patch_view?id=75</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php <nowiki>Re: visibility maps and heap_prune</nowiki>]
}}

{{TodoItem
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]
}}

{{TodoItem
|Bias FSM towards returning free space near the beginning of the heap file, in hopes that empty pages at the end can be truncated by VACUUM
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php <nowiki>FSM search modes</nowiki>]
}}

{{TodoItem
|Consider a more compact data representation for dead tuple locations within VACUUM
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php <nowiki>Re: Have vacuum emit a warning when it runs out of maintenance_work_mem</nowiki>]
}}

{{TodoItem
|Provide more information in order to improve user-side estimates of dead space bloat in relations
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]
}}

{{TodoItem
|Improve locking behaviour of vacuum during trailing page truncation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00319.php
* http://archives.postgresql.org/message-id/4D8DF88E.7080205@Yahoo.com
}}

{{TodoItem
|Reduce the number of table scans performed by vacuum
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00605.php
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php
}}

=== Auto-vacuum ===
{{TodoSubsection}}

{{TodoItemEasy
|Issue log message to suggest VACUUM FULL if a table is nearly empty?}}

{{TodoItem
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can do that.
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]
}}

{{TodoItem
|Prevent autovacuum from running if an old transaction is still running from the last vacuum
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]
}}

{{TodoItem
|Have autoanalyze of parent tables occur when child tables are modified
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php
* http://archives.postgresql.org/pgsql-performance/2010-10/msg00271.php
}}

{{TodoItem
|Allow parallel cores to be used by vacuumdb
* [http://archives.postgresql.org/message-id/4F10A728.7090403@agliodbs.com vacuumdb -j]
}}

{{TodoEndSubsection}}

== Locking ==

{{TodoItem
|Fix priority ordering of read and write light-weight locks
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php <nowiki>lwlocks and starvation</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php <nowiki>Re: lwlocks and starvation</nowiki>]
}}

{{TodoItem
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]
}}

{{TodoItem
|Allow UPDATEs on only non-referential integrity columns not to conflict with referential integrity locks
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php <nowiki>Referential Integrity and SHARE locks</nowiki>]
}}

{{TodoItem
|Add idle_in_transaction_timeout GUC so locks are not held for long periods of time}}

{{TodoItem
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]
}}

{{TodoItem
|Detect deadlocks involving LockBufferForCleanup()
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
}}

{{TodoItem
|Allow finer control over who is cancelled in a deadlock
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01727.php
}}

{{TodoItem
|Consider a lock timeout parameter
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00485.php <nowiki>SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5</nowiki>]
}}

{{TodoItemDone
|Reduce number of unnecessary false positives in Serializable Snapshot Isolation
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00609.php <nowiki>SSI heap_insert and page-level predicate locks</nowiki>]
}}

== Startup Time Improvements ==

{{TodoItem
|Experiment with multi-threaded backend for backend creation
|This would prevent the overhead associated with process creation. Most operating systems have trivial process creation time compared to database startup overhead, but a few operating systems (Win32, Solaris) might benefit from threading. Also explore the idea of a single session using multiple threads to execute a statement faster.}}

{{TodoItem
|Allow backends to change their database without restart
|This allows for faster server startup.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00843.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00336.php
}}

== Write-Ahead Log ==

{{TodoItem
|Eliminate need to write full pages to WAL before page modification
|Currently, to protect against partial disk page writes, we write full page images to WAL before they are modified so we can correct any partial page writes during recovery. These pages can also be eliminated from point-in-time archive files.
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01191.php
* [http://archives.postgresql.org/message-id/20120105061916.GB21048@fetter.org WIP double writes]
* [http://archives.postgresql.org/message-id/4EFC449F02000025000441CD@gw.wicourts.gov double writes]
* [http://archives.postgresql.org/message-id/20120110214344.GB21106@fetter.org Double-write with Fast Checksums]
* [http://archives.postgresql.org/message-id/1962493974.656458.1327703514780.JavaMail.root@zimbra-prod-mbox-4.vmware.com double writes using "double-write buffer" approach]
}}

{{TodoItem
|When full page writes are off, write CRC to WAL and check file system blocks on recovery
|If CRC check fails during recovery, remember the page in case a later CRC for that page properly matches. The difficulty is that hint bits are not WAL logged, meaning a valid page might not match the earlier CRC.}}

{{TodoItem
|Write full pages during file system write and not when the page is modified in the buffer cache
|This allows most full page writes to happen in the background writer. It might cause problems for applying WAL on recovery into a partially-written page, but later the full page will be replaced from WAL.
* [http://archives.postgresql.org/message-id/CAGvK12UST-tPhyLrSLuSpwFxZbAO79yYrhV2xaLmS2MkUxNUVQ@mail.gmail.com Page Checksums + Double Writes]
}}

{{TodoItem
|Reduce WAL traffic so only modified values are written rather than entire rows
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php <nowiki>Reduction in WAL for UPDATEs</nowiki>]
}}

{{TodoItem
|Allow WAL information to recover corrupted pg_controldata
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]
}}

{{TodoItem
|Find a way to reduce rotational delay when repeatedly writing last WAL page
|Currently fsync of WAL requires the disk platter to perform a full rotation to fsync again. One idea is to write the WAL to different offsets that might reduce the rotational delay.
* [http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php <nowiki>500 tpsQL + WAL log implementation</nowiki>]
}}

{{TodoItem
|Speed WAL recovery by allowing more than one page to be prefetched
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay.
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]
}}

{{TodoItem
|Improve WAL concurrency by increasing lock granularity
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]
}}

{{TodoItem
|Be more aggressive about creating WAL files
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php <nowiki>Re: PANIC caused by open_sync on Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-07/msg01075.php <nowiki>PreallocXlogFiles</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2005-04/msg00556.php <nowiki>WAL/PITR additional items</nowiki>]
}}

{{TodoItem
|Have resource managers report the duration of their status changes
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]
}}

{{TodoItem
|Move pgfoundry's xlogdump to /contrib and have it rely more closely on the WAL backend code
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php <nowiki>xlogdump</nowiki>]
}}

{{TodoItem
|Close deleted WAL files held open in *nix by long-lived read-only backends
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]
}}

== Optimizer / Executor ==

{{TodoItem
|Improve selectivity functions for geometric operators}}

{{TodoItem
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]
}}

{{TodoItem
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG}}

{{TodoItem
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}

{{TodoItem
|Consider compressed annealing to search for query plans
|This might replace GEQO.
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us
}}

{{TodoItem
|Improve use of expression indexes for ORDER BY
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php <nowiki>Resjunk sort columns, Heikki's index-only quals patch, and bug #5000</nowiki>]
}}

{{TodoItem
|Modify the planner to better estimate caching effects
* http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php
}}

{{TodoItem
|Allow shared buffer cache contents to affect index cost computations
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php
}}

=== Hashing ===
{{TodoSubsection}}

{{TodoItem
|Consider using a hash for joining to a large IN (VALUES ...) list
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]
}}

{{TodoItem
|Allow single batch hash joins to preserve outer pathkeys
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|"lazy" hash tables - look up only the tuples that are actually requested
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid building the same hash table more than once during the same query
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid hashing for distinct and then re-hashing for hash join
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoEndSubsection}}

== Background Writer ==

{{TodoItem
|Consider having the background writer update the transaction status hint bits before writing out the page
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.}}

{{TodoItem
|Consider adding buffers the background writer finds reusable to the free list
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]
}}

{{TodoItem
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]
}}

{{TodoItem
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]
}}

{{TodoItem
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]
}}

== Concurrent Use of Resources ==

{{TodoItem
|Do async I/O for faster random read-ahead of data
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-09/msg00255.php <nowiki>Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-01/msg00170.php <nowiki>Bitmap index scan preread using posix_fadvise (Was: There's random access and then there's random access)</nowiki>]
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]
}}

{{TodoItem
|Experiment with multi-threaded backend for better I/O utilization
|This would allow a single query to make use of multiple I/O channels simultaneously. One idea is to create a background reader that can pre-fetch sequential and index scan pages needed by other backends. This could be expanded to allow concurrent reads from multiple devices in a partitioned table.
* http://archives.postgresql.org/pgsql-performance/2011-02/msg00123.php
}}

{{TodoItem
|Experiment with multi-threaded backend for better CPU utilization
|This would allow several CPUs to be used for a single query, such as for sorting or query execution.
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00945.php <nowiki>Multi CPU Queries - Feedback and/or suggestions wanted!</nowiki>]
}}

{{TodoItem
|SMP scalability improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

== TOAST ==

{{TodoItem
|Allow user configuration of TOAST thresholds
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]
}}

{{TodoItem
|Reduce unnecessary cases of deTOASTing
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]
}}

{{TodoItem
|Reduce costs of repeat de-TOASTing of values
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]
}}

== Monitoring ==
{{TodoItem
|Expand pg_stat_activity for easier integration with monitoring tools
|* http://archives.postgresql.org/message-id/4DFA13A5.2060200@2ndQuadrant.com
}}

{{TodoItem
|Add column to pg_stat_activity that shows the progress of long-running commands like CREATE INDEX and VACUUM
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00203.php <nowiki>EXPLAIN progress info</nowiki>]
* The CLUSTER/VACUUM FULL implementation would also be useful to track this way
}}

{{TodoItem
|Have pg_stat_activity display query strings in the correct client encoding
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php <nowiki>pg_stats queries versus per-database encodings</nowiki>]
}}

{{TodoItemEasy
|Expose pg_controldata via an SQL interface
|Helpful for monitoring replicated databases
* http://archives.postgresql.org/message-id/4B901D73.8030003@agliodbs.com
* [http://archives.postgresql.org/message-id/4B959D7A.6010907@joeconway.com initial patch]
}}

== Miscellaneous Performance ==

{{TodoItem
|Use mmap() rather than SYSV for shared buffers?
|This would remove the requirement for SYSV SHM but would introduce portability issues. Anonymous mmap (or mmap to /dev/zero) is required to prevent I/O overhead. We could also consider mmap() for writing WAL.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00750.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00756.php
}}

{{TodoItem
|Rather than consider mmap()-ing in 8k pages, consider mmap()'ing entire files into a backend?
|Doing I/O to large tables would consume a lot of address space or require frequent mapping/unmapping. Extending the file also causes mapping problems that might require mapping only individual pages, leading to thousands of mappings. Another problem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk before WAL is written.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01239.php
}}

{{TodoItem
|Consider ways of storing rows more compactly on disk:
* Reduce the row header size?
* Consider reducing on-disk varlena length from four bytes to two because a heap row cannot be more than 64k in length}}

{{TodoItem
|Consider transaction start/end performance improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php <nowiki>Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

{{TodoItem
|Allow configuration of backend priorities via the operating system
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]
}}

{{TodoItem
|Consider increasing the minimum allowed number of shared buffers
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]
}}

{{TodoItem
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]
}}

{{TodoItem
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]
}}

{{TodoItem
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]
}}

{{TodoItem
|Sort large UPDATE/DELETEs so it is done in heap order
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]
}}

{{TodoItemDone
|Allow one transaction to see tuples using the snapshot of another transaction
|This would assist multiple backends in working together.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php <nowiki>Transaction Snapshot Cloning</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00260.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00466.php
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00684.php
}}

{{TodoItem
|Consider decreasing the I/O caused by updating tuple hint bits
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php
}}

{{TodoItem
|Avoid the requirement of freezing pages that are infrequently modified
|If all rows on a page are visible, it is possible to set a bit in the visibility map (once the visibility map is 100% reliable) and not need to freeze the page, avoiding a page rewrite
* http://archives.postgresql.org/message-id/4BF701CF.2090205@agliodbs.com
* http://archives.postgresql.org/pgsql-hackers/2010-06/msg00082.php
}}

{{TodoItem
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]
}}

{{TodoItem
|Restructure truncation logic to be more resistant to failure
|This also involves not writing dirty buffers for a truncated or dropped relation
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php
}}

{{TodoItem
|Consider adding logic to increase large tables by more than 8k
|This would reduce file system fragmentation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00337.php
}}

== Miscellaneous Other ==

{{TodoItem
|Deal with encoding issues for filenames in the server filesystem
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}
}}

{{TodoItem
|Deal with encoding issues in the output of localeconv()
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]
}}

{{TodoItem
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg00846.php <nowiki>patch - Report the schema along table name in a referential failure error message</nowiki>]
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]
}}

{{TodoItemEasy
| Provide [http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html#LIBPQ-CONNECT-FALLBACK-APPLICATION-NAME fallback_application_name] in contrib/pgbench, oid2name, and dblink.
* {{MessageLink|w2g9837222c1004070216u3bc46b3ahbddfdffdbfb46212@mail.gmail.com|fallback_application_name and pgbench}}
}}

{{TodoItem
|Add 64-bit support to /contrib/pgbench
* http://archives.postgresql.org/pgsql-hackers/2010-07/msg00153.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00705.php
}}

== Source Code ==

{{TodoItemDone
|Add use of 'const' for variables in source tree
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00473.php
}}

{{TodoItemEasy
|Remove warnings created by -Wcast-align}}

{{TodoItem
|Move platform-specific ps status display info from ps_status.c to ports}}

{{TodoItem
|Add optional CRC checksum to heap and index pages
|One difficulty is how to prevent hint bit changes from affecting the computed CRC checksum.
* http://archives.postgresql.org/message-id/19934.1226601952%40sss.pgh.pa.us
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00002.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01028.php <nowiki>double-buffering page writes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00524.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01101.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00011.php <nowiki>Re: Block-level CRC checks</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00249.php
* http://archives.postgresql.org/message-id/20111221215913.GA4536@fetter.org
* http://archives.postgresql.org/message-id/CA+U5nMJzQyxcObkpNAf1SYTX-gO_Mom3O9JXHnGpxRo1kXJ7ww@mail.gmail.com
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00128.php
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00113.php
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00172.php
* http://archives.postgresql.org/pgsql-hackers/2012-03/msg00001.php
* http://archives.postgresql.org/pgsql-hackers/2012-03/msg00188.php
}}

{{TodoItem
|Consider a faster CRC32 algorithm
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php
}}

{{TodoItem
|Allow cross-compiling by generating the zic database on the target system}}

{{TodoItem
|Improve NLS maintenance of libpgport messages linked onto applications}}

{{TodoItem
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}

{{TodoItem
|Allow creation of universal binaries for Darwin
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]
}}

{{TodoItem
|Consider GnuTLS if OpenSSL license becomes a problem
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]
}}

{{TodoItem
|Consider making NAMEDATALEN more configurable in future releases}}

{{TodoItem
|Research use of signals and sleep wake ups
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]
}}

{{TodoItem
|Allow C++ code to more easily access backend code
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]
}}

{{TodoItem
|Consider simplifying how memory context resets handle child contexts
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]
}}

{{TodoItem
|Create three versions of libpgport to simplify client code
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]
}}

{{TodoItem
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]
}}

{{TodoItem
|Implement the non-threaded Avahi service discovery protocol
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]
}}

{{TodoItem
|Reduce data row alignment requirements on some 64-bit systems
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]
}}

{{TodoItem
|Restructure TOAST internal storage format for greater flexibility
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]
}}

{{TodoItem
| Add regression tests for pg_dump/restore
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01967.php <nowiki>"make install-check-pg_dump" target in src/regress]</nowiki>]
}}

{{TodoItem
| Research different memory allocation methods for lists
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php
}}

{{TodoItem
| Consider removing the attribute options cache
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00039.php
}}

{{TodoItem
| Restructure /contrib section
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00705.php
}}

=== /contrib/pg_upgrade ===
{{TodoSubsection}}

{{TodoItem
|Handle large object comments
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.
}}

{{TodoItem
|Consider using pg_depend for checking object usage in version.c
}}

{{TodoItem
|If reindex is necessary, allow it to be done in parallel with pg_dump custom format
}}

{{TodoItem
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary
|pg_class.oid is not preserved so schema.tablename must be used.
* [http://archives.postgresql.org/message-id/CAAZKuFaWdLkK8eozSAooZBets9y_mfo2HS6urPAKXEPbd-JLCA@mail.gmail.com pg_upgrade and statistics]
}}

{{TodoItem
|Improve testing, perhaps using the buildfarm
|The buildfarm has access to multiple versions of PostgreSQL.
}}

{{TodoItem
|Create machine-readable output of pg_controldata
|This would avoid parsing its output. The problem is we need pg_controldata output from both the old and new clusters so we would need to support both formats.
}}

{{TodoEndSubsection}}

=== Windows ===
{{TodoSubsection}}

{{TodoItem
|Remove configure.in check for link failure when cause is found}}

{{TodoItem
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}

{{TodoItem
|Allow psql to use readline once non-US code pages work with backslashes}}

{{TodoItem
|Fix problem with shared memory on the Win32 Terminal Server}}

{{TodoItem
|Improve signal handling
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]
}}

{{TodoItem
|Convert MSVC build system to remove most batch files
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]
}}

{{TodoItem
|Support pgxs when using MSVC}}

{{TodoItem
|Fix MSVC NLS support, like for to_char()
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php <nowiki>Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)</nowiki>]
}}

{{TodoItem
|Find a correct rint() substitute on Windows
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]
}}

{{TodoItem
|Fix global namespace issues when using multiple terminal server sessions
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}

{{TodoItem
|Change from the current autoconf/gmake build system to cmake
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01869.php <nowiki>About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)</nowiki>]
}}

{{TodoItem
|Improve consistency of path separator usage
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net
}}

{{TodoItem
|Fix cross-compiling on Windows
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php
}}

{{TodoItemDone
|Allow multiple Postgres clusters running on the same machine to distinguish themselves in the event log
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01297.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00574.php
}}

{{TodoEndSubsection}}

=== Wire Protocol Changes ===
{{TodoSubsection}}

{{TodoItem
|Allow dynamic character set handling}}

{{TodoItem
|Add decoded type, length, precision}}

{{TodoItem
|Mark result columns as known-not-null when possible
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]
}}

{{TodoItem
|Provide more control over planner treatment of statements being prepared}}

{{TodoItem
|Use compression?}}

{{TodoItem
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}

{{TodoItem
|Set protocol for wire format negotiation
* [http://archives.postgresql.org/message-id/CACMqXCKkGrGXxQhjHCKCe0B8hn6sTt-1sdgHZOSGQMxrusOsQA@mail.gmail.com GUC_REPORT for protocol tunables]
}}

{{TodoItem
|Make sure upgrading to a 4.1 protocol version will actually work smoothly
* [http://archives.postgresql.org/message-id/28307.1318255008@sss.pgh.pa.us Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable]
}}

{{TodoEndSubsection}}

== Documentation ==

{{TodoItem
|Convert single quotes to apostrophes in the PDF documentation
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]
}}

{{TodoItem
|Provide a manpage for postgresql.conf
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Consider changing documentation format from SGML to XML
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]
* http://archives.postgresql.org/pgsql-docs/2011-04/msg00020.php
* http://wiki.postgresql.org/wiki/Switching_PostgreSQL_documentation_from_SGML_to_XML
}}

{{TodoItem
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com
}}

{{TodoItem
|Add diagrams to the documentation
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php
}}

== Exotic Features ==

{{TodoItem
|Add pre-parsing phase that converts non-ISO syntax to supported syntax
|This could allow SQL written for other databases to run without modification.}}

{{TodoItem
|Allow plug-in modules to emulate features from other databases}}

{{TodoItem
|Add features of Oracle-style packages
|A package would be a schema with session-local variables, public/private functions, and initialization functions. It is also possible to implement these capabilities in any schema and not use a separate "packages" syntax at all.
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]
}}

{{TodoItem
|Consider allowing control of upper/lower case folding of unquoted identifiers
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00849.php <nowiki>TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
}}

{{TodoItem
|Add autonomous transactions
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]
}}

{{TodoItem
|Give query progress indication
* [[Query progress indication]]
}}

{{TodoItem
|Rethink our type system
* [[Rethinking datatypes]]
}}

== Features We Do ''Not'' Want ==

The following features have been discussed ad nauseum on the PostgreSQL mailing lists and the consensus has been that the project is not interested in them. As such, if you are going to bring them up as potential features, you will want to be familiar with all of the arguments against these features which have been previously made over the years. If you decide to work on such features anyway, you should be aware that you face a higher-than-normal barrier to get the Project to accept them.

{{TodoItem
|All backends running as threads in a single process (not wanted)
|This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. Threading specific operations such as I/O, seq scans, and connection management has been discussed and will probably be implemented to enable specific performance features. Moving to a threaded engine would also require halting all other work on PostgreSQL for one to two years.}}

{{TodoItem
|"Oracle-style" optimizer hints (not wanted)
|Optimizer hints, as implemented in Oracle and other RDBMSes, are used to work around problems in the optimizer and introduce upgrade and maintenance issues. We would rather have such problems reported and fixed. We have discussed a more sophisticated system of per-class cost adjustment instead, but a specification remains to be developed. See [[OptimizerHintsDiscussion|Optimizer Hints Discussion]] for further information.}}

{{TodoItem
|Embedded server (not wanted)
|While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliably and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases. Besides, there are several very mature embedded SQL databases already available.}}

{{TodoItem
|Obfuscated function source code (not wanted)
|Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]
}}

{{TodoItem
|Indeterminate behavior for the GROUP BY clause (not wanted)
|At least one other database product allows specification of a subset of the result columns which GROUP BY would need to be able to provide predictable results; the server is free to return any value from the group. This is not viewed as a desirable feature. PostgreSQL 9.1 allows result columns that are not referenced by GROUP BY if a primary key for the same table is referenced in GROUP BY.
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]
}}

</div>

[[Category:Todo]]

Todo

2012-02-22T23:43:54Z

Petere: Add: Run check constraints only when affected columns are changed

<div style="margin: 1ex 1em; float: right;">
__TOC__
</div>

This list contains '''all known PostgreSQL bugs and feature requests'''. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].

* {{TodoPending}} - marks ordinary, incomplete items
* {{TodoEasy}} - marks items that are easier to implement
* {{TodoDone}} - marks changes that are done, and will appear in the PostgreSQL 9.2 release.

For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the mailing list.</b>

<div style="padding: 1ex 4em;">
== Administration ==

{{TodoItem
|Allow administrators to cancel multi-statement idle transactions
|This allows locks to be released, but it is complex to report the cancellation back to the client.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php <nowiki>Cancelling idle in transaction state</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00441.php <nowiki>Re: Cancelling idle in transaction state</nowiki>]
}}

{{TodoItem
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]
}}

{{TodoItem
|Set proper permissions on non-system schemas during db creation
|Currently all schemas are owned by the super-user because they are copied from the template1 database. However, since all objects are inherited from the template database, it is not clear that setting schemas to the db owner is correct.}}

{{TodoItem
|Allow log_min_messages to be specified on a per-module basis
|This would allow administrators to see more detailed information from specific sections of the backend, e.g. checkpoints, autovacuum, etc. Another idea is to allow separate configuration files for each module, or allow arbitrary SET commands to be passed to them. See also [[Logging Brainstorm]].}}

{{TodoItem
|Simplify creation of partitioned tables
|This would allow creation of partitioned tables without requiring creation of triggers or rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. See also [[Table partitioning]]
}}

{{TodoItem
|Allow custom variables to appear in pg_settings()
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]
}}

{{TodoItem
|Have custom variables be transaction-safe
* {{MessageLink|4B577E9F.8000505@dunslane.net|Custom GUCs still a bit broken}}
}}

{{TodoItem
|Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]
}}

{{TodoItem
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]
}}

{{TodoItem
|Provide a way to query the log collector subprocess to determine the name of the currently active log file
* [http://archives.postgresql.org/pgsql-general/2008-11/msg00418.php <nowiki>Current log files when rotating?</nowiki>]
}}

{{TodoItem
|Allow simpler reporting of the unix domain socket directory and allow easier configuration of its default location
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01555.php
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01482.php
}}

{{TodoItem
|Allow custom daemons to be automatically stopped/started along with the postmaster
|This allows easier administration of daemons like user job schedulers or replication-related daemons.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01701.php <nowiki>Re: scheduler in core</nowiki>]
}}

{{TodoItem
|Improve logging of prepared transactions recovered during startup
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>"recovering prepared transaction" after server restart message</nowiki>]
}}

{{TodoItem
|Consider using POSIX shared memory to avoid System V shared memory kernel limits
* [http://archives.postgresql.org/message-id/4DFA2673.3010009@enterprisedb.com <nowiki>POSIX shared memory patch status</nowiki>]
}}

{{TodoItemDone
|Address problem where superusers are assumed to be members of all groups
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
}}

=== Configuration files ===
{{TodoSubsection}}

{{TodoItemEasy
|Change pg_ident.conf parsing to be the same as pg_hba.conf
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg02204.php
}}

{{TodoItem
|Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00764.php
}}

{{TodoItem
|Consider normalizing fractions in postgresql.conf, perhaps using '%'
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]
}}

{{TodoItem
|Allow Kerberos to disable stripping of realms so we can check the username@realm against multiple realms
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php <nowiki>krb_match_realm patch</nowiki>]
}}

{{TodoItem
|Improve LDAP authentication configuration options
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php <nowiki>Proposed Patch - LDAPS support for servers on port 636 w/o TLS</nowiki>]
}}

{{TodoItem
|Add external tool to auto-tune some postgresql.conf parameters
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php <nowiki>Simple postgresql.conf wizard</nowiki>]
}}

{{TodoItem
|Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php <nowiki>Re: Plans for 8.4</nowiki>]
}}

{{TodoItem
|Process pg_hba.conf keywords as case-insensitive
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00432.php <nowiki>More robust pg_hba.conf parsing/error logging</nowiki>]
}}

{{TodoItem
|Create utility to compute accurate random_page_cost value
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00162.php
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00362.php
}}

{{TodoItem
|Allow configuration files to be independently validated
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php
* http://archives.postgresql.org/message-id/12666.1310774573@sss.pgh.pa.us
}}

{{TodoItem
|Allow postgresql.conf settings to be accepted by backends even if some settings are invalid for those backends
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoItem
|Allow all backends to receive postgresql.conf setting changes at the same time
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoEndSubsection}}

=== Tablespaces ===
{{TodoSubsection}}

{{TodoItem
|Allow a database in tablespace t1 with tables created in tablespace t2 to be used as a template for a new database created with default tablespace t2
|Currently all objects in the default database tablespace must have default tablespace specifications. This is because new databases are created by copying directories. If you mix default tablespace tables and tablespace-specified tables in the same directory, creating a new database from such a mixed directory would create a new database with tables that had incorrect explicit tablespaces. To fix this would require modifying pg_class in the newly copied database, which we don't currently do.}}

{{TodoItem
|Allow reporting of which objects are in which tablespaces
|This item is difficult because a tablespace can contain objects from multiple databases. There is a server-side function that returns the databases which use a specific tablespace, so this requires a tool that will call that function and connect to each database to find the objects in each database for that tablespace.}}

{{TodoItem
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original}}

{{TodoItem
|Allow per-tablespace quotas}}

{{TodoItem
|Allow tablespaces on RAM-based partitions for unlogged tables
* http://archives.postgresql.org/pgsql-advocacy/2011-05/msg00033.php
}}

{{TodoItem
|Allow toast tables to be moved to a different tablespace
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00980.php
* {{messageLink|CAFEQCbH756DyyAPQ1ykh3+b+kE1-EhWRww1WO_x5v38C-uLnUg@mail.gmail.com|patch : Allow toast tables to be moved to a different tablespace}} (issues remain)
* [http://archives.postgresql.org/message-id/CAFEQCbEq07OopgE5xFYv2Q3eMq45hRSJkjCBO+kvpJq9NEVhow@mail.gmail.com Allow toast tables to be moved to a different tablespace]
}}

{{TodoEndSubsection}}

=== Statistics Collector ===
{{TodoSubsection}}

{{TodoItem
|Allow statistics last vacuum/analyze execution times to be displayed without requiring track_counts to be enabled
* [http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php <nowiki>row-level stats and last analyze time</nowiki>]
}}

{{TodoItem
|Clear table counters on TRUNCATE
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php <nowiki>Small TRUNCATE glitch</nowiki>]
}}

{{TodoEndSubsection}}

=== SSL ===
{{TodoSubsection}}

{{TodoItem
|Allow SSL authentication/encryption over unix domain sockets
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00924.php <nowiki>Re: Spoofing as the postmaster</nowiki>]
}}

{{TodoItem
|Allow SSL key file permission checks to be optionally disabled when sharing SSL keys with other applications
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php <nowiki>BUG #3809: SSL "unsafe" private key permissions bug</nowiki>]
}}

{{TodoItem
|Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart
|Unlike SSL CRT files, CRL (Certificate Revocation List) files are updated frequently
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00832.php <nowiki>Automatic CRL reload</nowiki>]
Alternatively or additionally supporting OCSP (online certificate security protocol) would provide real-time revocation discovery without reloading
}}

{{TodoItem
| Allow automatic selection of SSL client certificates from a certificate store
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]
}}

{{TodoItem
| Send the full certificate server chain to the client
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]
}}

{{TodoEndSubsection}}

=== Point-In-Time Recovery (PITR) ===
{{TodoSubsection}}

{{TodoItemEasy
|Create dump tool for write-ahead logs for use in determining transaction id for point-in-time recovery
|This is useful for checking PITR recovery.}}

{{TodoItem
|Allow archive_mode to be changed without server restart?
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php <nowiki>Enabling archive_mode without restart</nowiki>]
}}

{{TodoItem
|Consider avoiding WAL switching via archive_timeout if there has been no database activity
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01469.php <nowiki>archive_timeout behavior for no activity</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg00395.php <nowiki>Re: archive_timeout behavior for no activity</nowiki>]
}}

{{TodoEndSubsection}}

=== Standby server mode ===
{{TodoSubsection}}

{{TodoItem
| Allow pg_xlogfile_name() to be used in recovery mode
* [http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12@mail.gmail.com <nowiki>Streaming replication and pg_xlogfile_name()</nowiki>]
}}

{{TodoItem
| Prevent variables inherited from the server environment from begin used for making streaming replication connections.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01011.php <nowiki>Re: Parameter name standby_mode</nowiki>]
}}

{{TodoItemDone
| Allow hot file system backups on standby servers
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01727.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
}}

{{TodoItem
| Change walsender so that it applies per-role settings
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00642.php
}}

{{TodoItemDone
| Add more control over waiting for synchronous commit
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01611.php
}}

{{TodoItem
| Restructure configuration parameters for standby mode
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01820.php
}}

{{TodoItem
| Allow time-delayed application of logs on the standby
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00992.php
}}
{{TodoItem
| Add -X parameter to pg_basebackup to specify a different directory for px_xlog, like initdb
}}

{{TodoEndSubsection}}

== Data Types ==

{{TodoItem
|Fix data types where equality comparison is not intuitive, e.g. box
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01643.php
}}

{{TodoItem
|Add support for public SYNONYMs
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php
* http://archives.postgresql.org/pgsql-general/2010-12/msg00139.php
}}

{{TodoItem
|Add support for SQL-standard GENERATED/IDENTITY columns
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]
}}

{{TodoItem
|Consider placing all sequences in a single table, or create a system view
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2012-02/msg00258.php Removing special case OID generation]
}}

{{TodoItem
|Consider a special data type for regular expressions
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]
}}

{{TodoItem
|Reduce BIT data type overhead using short varlena headers
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php <nowiki>storage size of "bit" data type..</nowiki>]
}}

{{TodoItem
|Allow renaming and deleting enumerated values from an existing enumerated data type
}}

{{TodoItem
|Support scoped IPv6 addresses in the inet type
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php <nowiki>strange problem with ip6</nowiki>]
}}

{{TodoItemDone
|Add a JSON (JavaScript Object Notation) data type
|This would behave similar to the XML data type, which is stored as text, but allows element lookup and conversion functions.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01494.php <nowiki>PATCH: Add hstore_to_json()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg00001.php <nowiki>Re: PATCH: Add hstore_to_json()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg01092.php <nowiki>Proposal: Add JSON support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00057.php <nowiki>Re: Proposal: Add JSON support</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00481.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01694.php
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg00219.php
}}

{{TodoItem
|Considering improving performance of computing CHAR() value lengths
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00900.php <nowiki>char() overhead on read-only workloads not so insignifcant as the docs claim it is...</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01787.php <nowiki>Re: [PATCH] backend: compare word-at-a-time in bcTruelen</nowiki>]
}}

{{TodoItem
|Add overlaps geometric operators that ignore point overlaps
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00861.php
}}

{{TodoItem
| Add IMMUTABLE column attribute
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00623.php
}}

=== Domains ===
{{TodoSubsection}}

{{TodoItem
|Allow functions defined as casts to domains to be called during casting
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]
}}

{{TodoItem
|Allow values to be cast to domain types
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00812.php
}}

{{TodoItem
|Make domains work better with polymorphic functions
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]
}}

{{TodoEndSubsection}}

=== Dates and Times ===
{{TodoSubsection}}

{{TodoItem
|Allow infinite intervals just like infinite timestamps
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00076.php
}}

{{TodoItem
|Determine how to represent date/time field extraction on infinite timestamps
* [http://archives.postgresql.org/message-id/CA+mi_8bda-Fnev9iXeUbnqhVaCWzbYhHkWoxPQfBca9eDPpRMw@mail.gmail.com extract(epoch from infinity) is not 0]
* [http://archives.postgresql.org/message-id/CADAkt-icuESH16uLOCXbR-dKpcvwtUJE4JWXnkdAjAAwP6j12g@mail.gmail.com converting between infinity timestamp and float8]
}}

{{TodoItem
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules.
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]
}}

{{TodoItem
|Have timestamp subtraction not call justify_hours()?
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]
}}

{{TodoItem
|Improve TIMESTAMP WITH TIME ZONE subtraction to be DST-aware
|Currently subtracting one date from another that crosses a daylight savings time adjustment can return '1 day 1 hour', but adding that back to the first date returns a time one hour in the future. This is caused by the adjustment of '25 hours' to '1 day 1 hour', and '1 day' is the same time the next day, even if daylight savings adjustments are involved.}}

{{TodoItem
|Fix interval display to support values exceeding 2^31 hours}}

{{TodoItem
|Add overflow checking to timestamp and interval arithmetic}}

{{TodoItem
|Add function to allow the creation of timestamps using parameters
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00232.php
}}

{{TodoEndSubsection}}

=== Arrays ===
{{TodoSubsection}}

{{TodoItem
|Add support for arrays of domains
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php <nowiki>Re: updated WIP: arrays of composites</nowiki>]
}}

{{TodoItem
|Allow single-byte header storage for array elements}}

{{TodoItem
|Add function to detect if an array is empty
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php <nowiki>Re: array_length()</nowiki>]
}}

{{TodoItem
|Improve handling of empty arrays
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php <nowiki>So what's an "empty" array anyway?</nowiki>]
}}

{{TodoItem
|Improve handling of NULLs in arrays
* [http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php <nowiki>BUG #4509: array_cat's null behaviour is inconsistent</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php
}}

{{TodoEndSubsection}}

=== Binary Data ===
{{TodoSubsection}}

{{TodoItem
|Improve vacuum of large objects, like contrib/vacuumlo?}}

{{TodoItem
|Auto-delete large objects when referencing row is deleted
|contrib/lo offers this functionality.}}

{{TodoItem
|Allow read/write into TOAST values like large objects
|Writing might require the TOAST column to be stored EXTERNAL.
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00049.php
}}

{{TodoItem
|Add API for 64-bit large object access
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00781.php <nowiki>64-bit API for large objects</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01790.php
}}

{{TodoEndSubsection}}

=== MONEY Data Type ===
{{TodoSubsection}}

{{TodoItem
|Add locale-aware MONEY type, and support multiple currencies
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]
}}

{{TodoItem
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}

{{TodoEndSubsection}}

=== Text Search ===
{{TodoSubsection}}

{{TodoItem
|Allow dictionaries to change the token that is passed on to later dictionaries
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]
}}

{{TodoItem
|Consider a function-based API for '@@' searches
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Simplifying Text Search</nowiki>]
}}

{{TodoItem
|Improve text search error messages
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php <nowiki>Re: Poorly designed tsearch NOTICEs</nowiki>]
}}

{{TodoItem
|Consider changing error to warning for strings larger than one megabyte
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00062.php <nowiki>Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
}}

{{TodoItem
|tsearch and tsdicts regression tests fail in Turkish locale on glibc
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]
}}

{{TodoItem
|tsquery negator operator treated as part of lexeme
* [http://archives.postgresql.org/pgsql-bugs/2009-06/msg00346.php BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation]
}}

{{TodoItem
|Improve handling of dash and plus signs in email address user names, and perhaps improve URL parsing
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00772.php
* [http://archives.postgresql.org/message-id/E1Ri8il-0008Ct-9p@wrigleys.postgresql.org tsearch does not recognize all valid emails]
}}

{{TodoItem
|Improve default parser, to more easily allow adding new tokens
* http://archives.postgresql.org/message-id/23485.1297727826@sss.pgh.pa.us
}}

{{TodoItem
|Add additional support functions
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00319.php
}}

{{TodoEndSubsection}}

=== XML ===
{{TodoSubsection}}

{{TodoItem
|Allow XML arrays to be cast to other data types
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
}}

{{TodoItem
|Add XML Schema validation and xmlvalidate functions (SQL:2008)}}

{{TodoItem
|Add xmlvalidatedtd variant to support validating against a DTD?}}

{{TodoItem
|Relax-NG validation; libxml2 supports this already}}

{{TodoItem
|Allow reliable XML operation non-UTF8 server encodings (xpath(), in particular, is known to not work)
* [http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php <nowiki>BUG #4622: xpath only work in utf-8 server encoding</nowiki>]
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}

{{TodoItem
|Add functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}

{{TodoItem
|Add XMLNAMESPACES support in XMLELEMENT and elsewhere}}

{{TodoItem
|Move XSLT from contrib/xml2 to a more reasonable location
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00539.php
}}

{{TodoItem
|Report errors returned by the XSLT library
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00562.php
}}

{{TodoItem
|Improve the XSLT parameter passing API
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00416.php
}}

{{TodoItem
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}

{{TodoItem
|Add pretty-printed XML output option
|Parse a document and serialize it back in some indented form. libxml2 might support this.}}

{{TodoItem
|Add XMLQUERY (from the SQL/XML standard)}}

{{TodoItem
|Allow XML sthredding
|In some cases shredding could be better option (if there is no need to keep XML docs entirely, e.g. if we have already developed tools that understand only relational data. This would be a separate module that implements annotated schema decomposition technique, similar to DB2 and SQL Server functionality.}}

{{TodoItem
|Fix Nested or repeated xpath() that apparently mess up namespaces [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00097.php] [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00144.php] [http://archives.postgresql.org/pgsql-general/2008-03/msg00295.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/message-id/004f01c90e91$138e9d10$3aabd730$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|XPath: Adding the <x> at the root causes problems [http://archives.postgresql.org/pgsql-bugs/2008-05/msg00184.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/pgsql-general/2008-07/msg00613.php]}}

{{TodoItem
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}

{{TodoItem
|xpath_table is pretty broken anyway [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php]}}

{{TodoItem
|better handling of XPath data types [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php] [http://archives.postgresql.org/message-id/004a01c90e90$4b986d90$e2c948b0$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|Improve handling of PIs and DTDs in xmlconcat() [http://archives.postgresql.org/message-id/200904211211.n3LCB09p008988@wwwmaster.postgresql.org]}}

{{TodoItem
|Restructure XML and /contrib/xml2 functionality
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02314.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00017.php
}}

{{TodoEndSubsection}}

== Functions ==

{{TodoItem
|Allow INET subnet comparisons using non-constants to be indexed}}

{{TodoItem
|Add an INET overlaps operator, for use by exclusion constraints
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00845.php
}}

{{TodoItem
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php <nowiki>RFC for adding typmods to functions</nowiki>]
}}

{{TodoItem
|Fix IS OF so it matches the ISO specification, and add documentation
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]
}}

{{TodoItem
|Implement Boyer-Moore searching in LIKE queries
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}
}}

{{TodoItem
|Prevent malicious functions from being executed with the permissions of unsuspecting users
|Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]
}}

{{TodoItem
|Reduce memory usage of aggregates in set returning functions
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]
}}

{{TodoItem
|Fix /contrib/ltree operator
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]
}}

{{TodoItem
|Fix /contrib/btree_gist's implementation of inet indexing
* [http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php <nowiki>BUG #5705: btree_gist: Index on inet changes query result</nowiki>]
}}

{{TodoItem
|<nowiki>Fix inconsistent precedence of =, >, and < compared to <>, >=, and <=</nowiki>
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php <nowiki>BUG #3822: Nonstandard precedence for comparison operators</nowiki>]
}}

{{TodoItem
|Fix regular expression bug when using complex back-references
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php <nowiki>BUG #3645: regular expression back references seem broken</nowiki>]
}}

{{TodoItem
|Have /contrib/dblink reuse unnamed connections
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php <nowiki>dblink un-named connection doesn't get re-used</nowiki>]
}}

{{TodoItem
|Improve formatting of pg_get_viewdef() output
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01648.php <nowiki>pg_get_viewdef formattiing</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01885.php <nowiki>Re: pretty print viewdefs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2011-12/msg00906.php reprise: pretty print viewdefs]
}}

{{TodoItem
|Add function to dump pg_depend information cleanly
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00226.php <nowiki>Elementary dependency look-up</nowiki>]
}}

{{TodoItemDone
|Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation
* [http://archives.postgresql.org/message-id/28488.1286461610@sss.pgh.pa.us pg_relation_size / could not open relation with OID #]
}}

=== Character Formatting ===

{{TodoSubsection}}
{{TodoItem
|Allow to_date() and to_timestamp() to accept localized month names}}

{{TodoItem
|Add missing parameter handling in to_char()
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]
}}

{{TodoItem
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]
}}

{{TodoItem
|Allow to_char() on interval values to accumulate the highest unit requested
|2= Some special format flag would be required to request such accumulation. Such functionality could also be added to EXTRACT. Prevent accumulation that crosses the month/day boundary because of the uneven number of days in a month.
* to_char(INTERVAL '1 hour 5 minutes', 'MI') => 65
* to_char(INTERVAL '43 hours 20 minutes', 'MI' ) => 2600
* to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') => 0:1:19:20
* to_char(INTERVAL '3 years 5 months','MM') => 41
}}

{{TodoItem
|Fix to_number() handling for values not matching the format string
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php <nowiki>Re: numeric_to_number() function skipping some digits</nowiki>]
}}

{{TodoEndSubsection}}

== Multi-Language Support ==

{{TodoItem
|Add NCHAR (as distinguished from ordinary varchar),}}

{{TodoItem
|Add a cares-about-collation column to pg_proc, so that unresolved-collation errors can be thrown at parse time
* [http://archives.postgresql.org/pgsql-hackers/2011-03/msg01520.php <nowiki>Open issues for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with text search configurations
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with to_char() and related functions
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Support collation-sensitive equality and hashing functions
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00472.php <nowiki> contrib/citext versus collations</nowiki>]
}}

{{TodoItem
|Add a LOCALE option to CREATE DATABASE, as a shorthand
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]
}}

{{TodoItem
|Support multiple simultaneous character sets, per SQL:2008}}

{{TodoItem
|Improve UTF8 combined character handling?}}

{{TodoItem
|Add octet_length_server() and octet_length_client()}}

{{TodoItem
|Make octet_length_client() the same as octet_length()?}}

{{TodoItem
|Fix problems with wrong runtime encoding conversion for NLS message files}}

{{TodoItem
|Add URL to more complete multi-byte regression tests
* [http://archives.postgresql.org/pgsql-hackers/2005-07/msg00272.php <nowiki>Multi-byte and client side character encoding tests for copy command..</nowiki>]
}}

{{TodoItem
|Fix contrib/fuzzystrmatch to work with multibyte encodings
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00138.php <nowiki> dmetaphone woes</nowiki>]
}}

{{TodoItem
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions
|Currently we preallocate memory based on worst-case usage.}}

{{TodoItem
|Add ability to use case-insensitive regular expressions on multi-byte characters
|Currently it works for UTF-8, but not other multi-byte encodings
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php <nowiki>Regexps vs. locale</nowiki>]
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}
}}

{{TodoItem
|Improve encoding of connection startup messages sent to the client
|Currently some authentication error messages are sent in the server encoding
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php <nowiki>encoding of PostgreSQL messages</nowiki>]
* [http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php <nowiki>Re: encoding of PostgreSQL messages</nowiki>]
}}

{{TodoItem
|More sensible support for Unicode combining characters, normal forms
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net
}}

== Views / Rules ==

{{TodoItem
|Automatically create rules on views so they are updateable, per SQL:2008
|We can only auto-create rules for simple views. For more complex cases users will still have to write rules manually.
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php <nowiki>Proposal for updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-08/msg00255.php <nowiki>Updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php <nowiki>Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle</nowiki>]
* http://wiki.postgresql.org/wiki/Updatable_views
}}

{{TodoItem
|Add the functionality of the WITH CHECK OPTION clause to CREATE VIEW}}

{{TodoItem
|Allow VIEW/RULE recompilation when the underlying tables change
|This is both difficult and controversial.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
* [http://archives.postgresql.org/message-id/CACk=U9NFSzWrEba8G5dZ=TZLy3_hx3QXGyCcKVWT=4iA1FjMuA@mail.gmail.com VIEW still referring to old name of field]
}}

{{TodoItem
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]
}}

{{TodoItem
|Add the ability to automatically create materialized views
|Right now materialized views require the user to create triggers on the main table to keep the summary table current. SQL syntax should be able to manage the triggers and summary table automatically. A more sophisticated implementation would automatically retrieve from the summary table when the main table is referenced, if possible. See [[Materialized Views]] for implementation details
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00479.php <nowiki>GSoC - proposal - Materialized Views in PostgreSQL</nowiki>]
}}

{{TodoItem
|Improve ability to modify views via ALTER TABLE
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]
}}

{{TodoItemDone
|Prevent low-cost functions from seeing unauthorized view rows
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg01346.php <nowiki>Using views for row-level access control is leaky</nowiki>]
}}

== SQL Commands ==

{{TodoItem
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT
* [http://dissipatedheat.com/2011/11/10/how-not-to-write-a-patch-for-postgresql/ How not to write this patch.]
}}

{{TodoItem
|Improve type determination of unknown (NULL or quoted literal) result columns for UNION/INTERSECT/EXCEPT
* [http://archives.postgresql.org/message-id/9799.1302719551@sss.pgh.pa.us <nowiki>UNION construct type cast gives poor error message</nowiki>]
}}

{{TodoItem
|Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00838.php <nowiki>WIP: grouping sets support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00466.php <nowiki>Implementation of GROUPING SETS (T431: Extended grouping capabilities)</nowiki>]
}}

{{TodoItem
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables</nowiki>]
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]
}}

{{TodoItem
|Add a GUC variable to warn about non-standard SQL usage in queries}}

{{TodoItem
|Add SQL-standard MERGE/REPLACE/UPSERT command
|MERGE is typically used to merge two tables. REPLACE or UPSERT command does UPDATE, or on failure, INSERT. See [[SQL MERGE]] for notes on the implementation details.
}}

{{TodoItem
|Add NOVICE output level for helpful messages
|For example, have it warn about unjoined tables. This could also control automatic sequence/index creation messages.
}}

{{TodoItem
|Allow NOTIFY in rules involving conditionals}}

{{TodoItem
|Allow EXPLAIN to identify tables that were skipped because of constraint_exclusion
}}

{{TodoItem
|Simplify dropping roles that have objects in several databases}}

{{TodoItem
|Allow the count returned by SELECT, etc to be represented as an int64 to allow a higher range of values}}

{{TodoItem
|Add support for WITH RECURSIVE ... CYCLE
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php <nowiki>WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows</nowiki>]}}

{{TodoItem
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}

{{TodoItem
|Allow DISTINCT to work in multiple-argument aggregate calls}}

{{TodoItem
|Add comments on system tables/columns using the information in catalogs.sgml
|Ideally the information would be pulled from the SGML file automatically.}}

{{TodoItem
|Prevent the specification of conflicting transaction read/write options
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php <nowiki>Re: SET TRANSACTION and SQL Standard</nowiki>]
}}

{{TodoItem
|Support LATERAL subqueries
|Lateral subqueries can reference columns of tables defined outside the subquery at the same level, i.e. ''laterally''.
For example, a LATERAL subquery in a FROM clause could reference tables defined in the same FROM clause.
Currently only the columns of tables defined ''above'' subqueries are recognized.
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php <nowiki>LATERAL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php <nowiki>Re: LATERAL</nowiki>]
}}

{{TodoItem
|Prevent temporary tables created with ON COMMIT DELETE ROWS from repeatedly truncating the table on every commit if the table is already empty
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00842.php
* http://archives.postgresql.org/pgsql-performance/2010-03/msg00392.php
* http://archives.postgresql.org/pgsql-performance/2010-04/msg00046.php
}}

{{TodoItem
|Allow DELETE and UPDATE to be used with LIMIT and ORDER BY
* http://archives.postgresql.org/pgadmin-hackers/2010-04/msg00078.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01997.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00021.php
}}

{{TodoItemDone
|Improve caching of prepared query plans
}}

{{TodoItem
|Allow PREPARE of cursors}}

{{TodoItem
|Have DISCARD PLANS discard plans cached by functions
|DISCARD all should do the same.
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00431.php
}}

{{TodoItem
|Avoid multiple-evaluation of BETWEEN and IN arguments containing volatile expressions
* http://archives.postgresql.org/message-id/4D95B605.2020709@enterprisedb.com
}}

{{TodoItem
|Fix nested CASE-WHEN constructs
* http://archives.postgresql.org/message-id/4DDCEEB8.50602@enterprisedb.com
}}

=== CREATE ===
{{TodoSubsection}}

{{TodoItem
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}

{{TodoItem
|Have WITH CONSTRAINTS also create constraint indexes
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]
}}

{{TodoItem
|Move NOT NULL constraint information to pg_constraint
|Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. Another issue is that we should probably force NOT NULL to be propagated from parent tables to children, just as CHECK constraints are. (But then does dropping PRIMARY KEY affect children?)
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg01223.php
}}

{{TodoItem
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]
}}

{{TodoItem
|Add CREATE SCHEMA ... LIKE that copies a schema}}

{{TodoItem
|Fix CREATE OR REPLACE FUNCTION to not leave objects depending on the function in inconsistent state
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]
}}

{{TodoItem
|Allow temporary tables to exist as empty by default in all sessions
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php <nowiki>idea: global temp tables</nowiki>]
* [http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php <nowiki>Re: idea: global temp tables</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg01098.php <nowiki>global temporary tables</nowiki>]
}}

{{TodoItem
|Allow the creation of "distinct" types
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php <nowiki>Distinct types</nowiki>]
}}

{{TodoItem
|Consider analyzing temporary tables when they are first used in a query
|Autovacuum cannot analyze or vacuum temporary tables.
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php <nowiki>autovacuum and temp tables support</nowiki>]
}}

{{TodoItem
|Allow an unlogged table to be changed to logged
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00437.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00323.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00237.php
}}

{{TodoEndSubsection}}

=== UPDATE ===
{{TodoSubsection}}

{{TodoItem
|<nowiki>Allow UPDATE tab SET ROW (col, ...) = (SELECT...)</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg01308.php <nowiki>Re: [PATCHES] extension for sql update</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00865.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php <nowiki>Re: UPDATE using sub selects</nowiki>]
}}

{{TodoItem
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00016.php <nowiki>Re: Do we need a TODO? (was Re: Concurrently updating anupdatable view)</nowiki>]
}}

{{TodoItem
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows
|This is related to the previous item, which questions whether it even has the right semantics
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]
}}

{{TodoEndSubsection}}

=== ALTER ===
{{TodoSubsection}}

{{TodoItem
|Have ALTER TABLE RENAME of a SERIAL column rename the sequence
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
* [http://archives.postgresql.org/message-id/CADLWmXUV4LbLhMZL8rYMhCy72aZZLB5BSARPQVgoX0BrxA0FFg@mail.gmail.com renaming implicit sequences]
}}

{{TodoItem
|Have ALTER SEQUENCE RENAME rename the sequence name stored in the sequence table
* [http://archives.postgresql.org/pgsql-bugs/2007-09/msg00092.php <nowiki>BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00007.php <nowiki>Re: BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItemEasy
|Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME or ALTER TABLE RENAME CONSTRAINT
* [http://archives.postgresql.org/pgsql-patches/2006-02/msg00168.php <nowiki>ALTER CONSTRAINT RENAME patch reverted</nowiki>]
}}

{{TodoItem
|Add ALTER DOMAIN to modify the underlying data type}}

{{TodoItem
|Allow ALTER TABLESPACE to move the tablespace to different directories}}

{{TodoItem
|Allow moving system tables to other tablespaces, where possible
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}

{{TodoItem
|Have ALTER INDEX update the name of a constraint using that index}}

{{TodoItem
|Allow column display reordering by recording a display, storage, and permanent id for every column?
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php <nowiki>Column reordering in pg_dump</nowiki>]
* http://archives.postgresql.org/message-id/1324412114-sup-9608@alvh.no-ip.org
}}

{{TodoItem
|Allow deactivating (and reactivating) indexes via ALTER TABLE
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01191.php
}}

{{TodoItem
|Add ALTER OPERATOR ... RENAME
|needs to consider effects of changing operator precedence
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]
}}

{{TodoItem
|Add ALTER TABLE ... RENAME RULE
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]
}}

{{TodoEndSubsection}}

=== CLUSTER ===
{{TodoSubsection}}

{{TodoItem
|Automatically maintain clustering on a table
|This might require some background daemon to maintain clustering during periods of low usage. It might also require tables to be only partially filled for easier reorganization. Another idea would be to create a merged heap/index data file so an index lookup would automatically access the heap data too. A third idea would be to store heap rows in hashed groups, perhaps using a user-supplied hash function.
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]
* http://community.enterprisedb.com/git/
* [http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php <nowiki>Re: maintain_cluster_order_v5.patch</nowiki>]
}}

{{TodoEndSubsection}}

=== COPY ===
{{TodoSubsection}}

{{TodoItem
|Allow COPY to report error lines and continue
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure.
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]
}}

{{TodoItem
|Allow COPY FROM to create index entries in bulk
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]
}}

{{TodoItem
|Allow COPY in CSV mode to control whether a quoted zero-length string is treated as NULL
|Currently this is always treated as a zero-length string, which generates an error when loading into an integer column
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php <nowiki>Re: [PATCHES] allow CSV quote in NULL</nowiki>]
}}

{{TodoItem
|Improve COPY performance
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01882.php
}}

{{TodoItem
|Allow COPY to report errors sooner
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]
}}

{{TodoItem
|Allow COPY to handle other number formats
|E.g. the German notation. Best would be something like WITH DECIMAL ','.
}}

{{TodoItem
|Allow a stalled COPY to exit if the backend is terminated
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00067.php <nowiki>Re: possible bug not in open items</nowiki>]
}}

{{TodoEndSubsection}}

=== GRANT/REVOKE ===
{{TodoSubsection}}

{{TodoItem
|Allow SERIAL sequences to inherit permissions from the base table?}}

{{TodoItem
|Allow dropping of a role that has connection rights
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php <nowiki>DROP ROLE dependency tracking ...</nowiki>]
}}
{{TodoEndSubsection}}

=== DECLARE CURSOR ===
{{TodoSubsection}}

{{TodoItem
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}

{{TodoItem
|Provide some guarantees about the behavior of cursors that invoke volatile functions
* [http://archives.postgresql.org/message-id/20997.1244563664@sss.pgh.pa.us Re: Cursor with hold emits the same row more than once across commits in 8.3.7]
}}

{{TodoEndSubsection}}

=== INSERT ===
{{TodoSubsection}}

{{TodoItem
|Allow INSERT/UPDATE of the system-generated oid value for a row}}

{{TodoItem
|In rules, allow VALUES() to contain a mixture of 'old' and 'new' references}}

{{TodoEndSubsection}}

=== SHOW/SET ===
{{TodoSubsection}}

{{TodoItem
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}

{{TodoItem
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count
* [http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php <nowiki>Re: [ADMIN] shared_buffers and shmmax</nowiki>]
}}

{{TodoEndSubsection}}

=== ANALYZE ===
{{TodoSubsection}}

{{TodoItem
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}

{{TodoItem
|Have EXPLAIN ANALYZE report rows as floating-point numbers
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg01363.php <nowiki>explain analyze rows=%.0f</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00108.php <nowiki>Re: explain analyze rows=%.0f</nowiki>]
}}

{{TodoItem
|Improve how ANALYZE computes in-doubt tuples
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]
}}

{{TodoEndSubsection}}

=== Window Functions ===
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.
{{TodoSubsection}}
{{TodoItem
|Support creation of user-defined window functions
|We have the ability to create new window functions written in C. Is it
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}

{{TodoItem
|Implement full support for window framing clauses
|In addition to done clauses described in the [http://developer.postgresql.org/pgdocs/postgres/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS latest doc], these clauses are not implemented yet.
* RANGE BETWEEN ... PRECEDING/FOLLOWING
* EXCLUDE
}}

{{TodoItem
|Investigate tuplestore performance issues
|The tuplestore_in_memory() thing is just a band-aid, we ought to try to solve it properly. tuplestore_advance seems like a weak spot as well.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php <nowiki>tuplestore potential performance problem</nowiki>]
}}

{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}

{{TodoItem
|Teach planner to evaluate multiple windows in the optimal order
|Currently windows are always evaluated in the query-specified order.
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64
}}

{{TodoItem
|Implement DISTINCT clause in window aggregates
|Some proprietary RDBMSs have implemented it already, so it helps with porting from those.}}

{{TodoEndSubsection}}

== Integrity Constraints ==
=== Keys ===

{{TodoSubsection}}

{{TodoItem
|Improve deferrable unique constraints for cases with many conflicts
|The current implementation fires a trigger for each potentially conflicting row. This might not scale well for an update that changes many key values at once.
}}

{{TodoEndSubsection}}

=== Referential Integrity ===
{{TodoSubsection}}

{{TodoItem
|Add MATCH PARTIAL referential integrity}}

{{TodoItem
|Change foreign key constraint for array -> element to mean element in array?
* [http://archives.postgresql.org/pgsql-hackers/2010-10/msg01814.php <nowiki>foreign keys for array/period contains relationships</nowiki>]
}}

{{TodoItem
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]
}}

{{TodoItem
|Optimize referential integrity checks
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php <nowiki>Can't ri_KeysEqual() consider two nulls as equal?</nowiki>]
}}

{{TodoEndSubsection}}

=== Check Constraints ===
{{TodoSubsection}}

{{TodoItem
|Run check constraints only when affected columns are changed
* http://archives.postgresql.org/message-id/1326055327.15293.13.camel@vanquo.pezone.net
}}

{{TodoEndSubsection}}

== Server-Side Languages ==

{{TodoItem
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}

{{TodoItem
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}

{{TodoItem
|Add more fine-grained specification of functions taking arbitrary data types
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php <nowiki>RfD: more powerful "any" types</nowiki>]
}}

{{TodoItem
|Implement stored procedures
|This might involve the control of transaction state and the return of multiple result sets
* [http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php <nowiki>PL/pgSQL stored procedure returning multiple result sets (SELECTs)?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php
* [http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php <nowiki>Gathering specs and discussion on feature (post 9.1)</nowiki>]
}}

{{TodoItem
|Allow holdable cursors in SPI}}

{{TodoItemEasy
|Add SPI_gettypmod() to return a field's typemod from a TupleDesc
* http://archives.postgresql.org/pgsql-hackers/2005-11/msg00250.php
}}

=== SQL-Language Functions ===
{{TodoSubsection}}

{{TodoItemDone
|Allow SQL-language functions to reference parameters by parameter name
|Currently SQL-language functions can only refer to dollar parameters, e.g. $1
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01479.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01519.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00221.php
}}

{{TodoItem
|Rethink query plan caching and timing of parse analysis within SQL-language functions
|They should work more like plpgsql functions do ...
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00078.php <nowiki>Re: BUG #6019: invalid cached plan on inherited table</nowiki>]
}}

{{TodoEndSubsection}}

=== PL/pgSQL ===
{{TodoSubsection}}

{{TodoItem
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}

{{TodoItem
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki>
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
}}

{{TodoItem
|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.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]
}}

{{TodoItem
|Consider keeping separate cached copies when search_path changes
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]
}}

{{TodoItem
|Improve handling of NULL row values vs. NULL rows
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php <nowiki>Null row vs. row of nulls in plpgsql</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01973.php
}}

{{TodoItem
|Improve PERFORM handling of WITH queries or document limitation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00309.php
}}

{{TodoEndSubsection}}

=== PL/Perl ===
{{TodoSubsection}}

{{TodoItem
|Allow regex operations in plperl using UTF8 characters in non-UTF8 encoded databases}}

{{TodoEndSubsection}}

=== PL/Python ===
{{TodoSubsection}}

{{TodoItem
|Develop a trusted variant of PL/Python.}}

{{TodoItem
|Create a new restricted execution class that will allow passing function arguments in as locals. Passing them as globals means functions cannot be called recursively.
* [http://archives.postgresql.org/pgsql-hackers/2011-02/msg01468.php <nowiki>Re: pl/python do not delete function arguments</nowiki>]
}}

{{TodoItem
|Add a DB-API compliant interface on top of the SPI interface
* http://petereisentraut.blogspot.com/2011/11/plpydbapi-db-api-for-plpython.html
}}

{{TodoItem
|For functions returning a setof record with a composite type, cache the I/O functions for the composite type
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02007.php
}}

{{TodoItem
|Fix loss of information during conversion of numeric type to Python float}}

{{TodoEndSubsection}}

=== PL/Tcl ===
{{TodoSubsection}}

{{TodoItem
|Add table function support}}

{{TodoItem
|Check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, and SPI calls.}}

{{TodoEndSubsection}}

== Clients ==

{{TodoItem
|Add a function like pg_get_indexdef() that report more detailed index information
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00166.php <nowiki>BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)</nowiki>]
}}

{{TodoItem
|Split out pg_resetxlog output into pre- and post-sections
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php
}}

=== pg_ctl ===
{{TodoSubsection}}

{{TodoItemDone
|Allow pg_ctl to work properly with configuration files located outside the PGDATA directory
|pg_ctl can not read the pid file because it isn't located in the config directory but in the PGDATA directory. The solution is to allow pg_ctl to read and understand postgresql.conf to find the data_directory value.
* [http://archives.postgresql.org/pgsql-bugs/2009-10/msg00024.php <nowiki>BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory</nowiki>]
}}

{{TodoItem
|Modify pg_ctl behavior and exit codes to make it easier to write an LSB conforming init script
|It may be desirable to condition some of the changes on a command-line switch, to avoid breaking existing scripts. A Linux shell (sh) script is referenced which has been tested and seems to provide a high degree of conformance in multiple environments. Study of this script might suggest areas where pg_ctl could be modified to make writing an LSB conforming script easier; however, some aspects of that script would be unnecessary with other suggested changes to pg_ctl, and discussion on the lists did not reach consensus on support for all aspects of this script. Further discussion of particular changes is needed before beginning any work.
* [[Lsb_conforming_init_script|LSB conforming init script]]
These threads should be studied for other ideas on improvements:
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01390.php <nowiki>We should Axe /contrib/start-scripts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01843.php <nowiki>Linux LSB init script</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00008.php <nowiki>Re: Linux LSB init script</nowiki>]
}}

{{TodoItem
|Improve pg_ctl's detection of running postmasters
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00000.php
* http://archives.postgresql.org/pgsql-committers/2011-06/msg00001.php
}}

{{TodoEndSubsection}}

=== psql ===
{{TodoSubsection}}

{{TodoItem
|Have psql \ds show all sequences and their settings
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00916.php <nowiki>Re: TODO item: Have psql show current values for a sequence</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00401.php <nowiki>Quick patch: Display sequence owner</nowiki>]
}}

{{TodoItemDone
|Have \d on a sequence indicate if the sequence is owned by a table}}

{{TodoItem
|Move psql backslash database information into the backend, use mnemonic commands?
|This would allow non-psql clients to pull the same information out of the database as psql.
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]
}}

{{TodoItem
|Make psql's \d commands more consistent in their handling of schemas
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php <nowiki>Re: psql and schemas</nowiki>]
}}

{{TodoItem
|Make psql's \d commands distinguish default privileges from no privileges
|ACL displays were visibly different for the two cases before we "improved" them by using array_to_string.
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00082.php <nowiki>BUG #6021: There is no difference between default and empty access privileges with \dp</nowiki>]
}}

{{TodoItem
|Consistently display privilege information for all objects in psql}}

{{TodoItemDone
|Add "auto" expanded mode that outputs in expanded format if "wrapped" mode can't wrap the output to the screen width
|Consider using auto-expanded mode for backslash commands like \df+.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00417.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01638.php
}}

{{TodoItem
|Prevent tab completion of SET TRANSACTION from querying the database and therefore preventing the transaction isolation level from being set.
|Currently SET <tab> causes a database lookup to check all supported session variables. This query causes problems because setting the transaction isolation level must be the first statement of a transaction.}}

{{TodoItemEasy
|\s without arguments (display history) fails with libedit, doesn't use pager either
* [http://archives.postgresql.org/pgsql-bugs/2011-06/msg00114.php <nowiki> psql \s not working - OS X</nowiki>]
}}

{{TodoItem
|Add a \set variable to control whether \s displays line numbers
|Another option is to add \# which lists line numbers, and allows command execution.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]
}}

{{TodoItem
|Include the symbolic SQLSTATE name in verbose error reports
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]
}}

{{TodoItem
|Add prompt escape to display the client and server versions
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00310.php <nowiki>WIP patch for TODO Item: Add prompt escape to display the client and server versions</nowiki>]
}}

{{TodoItem
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.
|Currently, "wrapped" format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}

{{TodoItem
|Support the ReST table output format
|Details about the ReST format: http://docutils.sourceforge.net/rst.html#reference-documentation
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg01007.php <nowiki>Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00518.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00609.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
}}

{{TodoItem
|Add option to print advice for people familiar with other databases
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php <nowiki>MySQL-ism help patch for psql</nowiki>]
}}

{{TodoItemDone
|\dd is missing comments for several types of objects
|Comments are not handled at all for some object types, and are handled by both \dd and the individual backslash command for others. Consider a system view like pg_comments to manage this mess.
* [http://archives.postgresql.org/pgsql-general/2009-09/msg00199.php <nowiki>comment on constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php <nowiki>pg_comments</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2011-05/msg00885.php <nowiki>patch: Allow \dd to show constraint comments</nowiki>]
}}

{{TodoItem
|Add ability to edit views with \ev
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00023.php <nowiki>Adding \ev view editor?</nowiki>]
}}

{{TodoItem
|Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php
}}

{{TodoItem
|Prevent psql from sending remaining single-line multi-statement queries after reconnecting
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php
}}

{{TodoItemEasy
|Add \i option to bring in the specified file as a quoted literal
|This would be useful for creating functions and other areas. Details still need to be worked out.
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00016.php
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00020.php
}}

{{TodoItem
|Consider having psql -c read .psqlrc, for consistency
|psql -f already reads .psqlrc
}}

{{TodoItem
|Allow processing of multiple -f (file) options
}}

{{TodoItem
|Improve line drawing characters
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00386.php
}}

{{TodoItem
|Consider improving the continuation prompt
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01772.php
}}

{{TodoEndSubsection}}

=== pg_dump / pg_restore ===
{{TodoSubsection}}

{{TodoItemEasy
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}

{{TodoItem
|Add pg_dumpall custom format dumps?
* [http://archives.postgresql.org/pgsql-general/2010-05/msg00509.php pg_dumpall custom format]
|}}

{{TodoItem
|Avoid using platform-dependent locale names in pg_dumpall output
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us
}}

{{TodoItem
|Allow selection of individual object(s) of all types, not just tables}}

{{TodoItem
|In a selective dump, allow dumping of an object and all its dependencies}}

{{TodoItem
|Add options like pg_restore -l and -L to pg_dump}}

{{TodoItem
|Add support for multiple pg_restore -t options, like pg_dump
|pg_restore's -t switch is less useful than pg_dump's in quite a few ways: no multiple switches, no pattern matching, no ability to pick up indexes and other dependent items for a selected table. It should be made to handle this switch just like pg_dump does.}}

{{TodoItem
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}

{{TodoItem
|Allow pg_dump --clean to drop roles that own objects or have privileges
|tgl says: if this is about pg_dumpall, it's done as of 8.4. If it's really about pg_dump, what does it mean? pg_dump has no business dropping roles.}}

{{TodoItem
|Allow pg_dump to utilize multiple CPUs and I/O channels by dumping multiple objects simultaneously
|The difficulty with this is getting multiple dump processes to produce a single dump output file. It also would require several sessions to share the same snapshot.
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00040.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02454.php
}}

{{TodoItem
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}

{{TodoItem
|Remove support for dumping from pre-7.3 servers
|In 7.3 and later, we can get accurate dependency information from the server. pg_dump still contains a lot of crufty code
to try to deal with the lack of dependency info in older servers, but the usefulness of maintaining that code grows small.}}

{{TodoItemDone
|Allow pre/data/post files when schema and data are dumped separately, for performance reasons
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00185.php <nowiki>Re: pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00821.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
}}

{{TodoItem
|Refactor handling of database attributes between pg_dump and pg_dumpall
|Currently only pg_dumpall emits database attributes, such as ALTER DATABASE SET commands and database-level GRANTs.
Many people wish that pg_dump would do that. One proposal is to let pg_dump issue such commands if the -C switch was used,
but it's unclear whether that will satisfy the demand.
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2010-05/msg00010.php summary of the issues]
}}

{{TodoItem
|Change pg_dump so that a comment on the dumped database is applied to the loaded database, even if the database has a different name.
|This will require new backend syntax, perhaps COMMENT ON CURRENT DATABASE. This is related to the previous item.}}

{{TodoItem
|Allow parallel restore of tar dumps
* [http://archives.postgresql.org/pgsql-hackers/2009-02/msg01154.php <nowiki>Re: parallel restore</nowiki>]
}}

{{TodoItemDone
|Allow pg_dumpall to output restorable ALTER USER/DATABASE SET settings
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00916.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00394.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02359.php
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg00489.php
}}

{{TodoEndSubsection}}

=== ecpg ===
{{TodoSubsection}}

{{TodoItem
|Docs
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}

{{TodoItem
|Solve cardinality > 1 for input descriptors / variables?}}

{{TodoItem
|Add a semantic check level, e.g. check if a table really exists}}

{{TodoItem
|fix handling of DB attributes that are arrays}}

{{TodoItem
|Fix nested C comments}}

{{TodoItemEasy
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}

{{TodoItem
|Make SET CONNECTION thread-aware, non-standard?}}

{{TodoItem
|Allow multidimensional arrays}}

{{TodoItem
|Implement COPY FROM STDIN}}

{{TodoItem
|Provide a way to specify size of a bytea parameter
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]
}}

{{TodoItemEasy
|Fix small memory leaks in ecpg
|Memory leaks in a short running application like ecpg are not really a problem, but make debugging more complicated}}

{{TodoItem
|Allow reuse of cursor name variables
* [http://archives.postgresql.org/message-id/20100329113435.GA3430@feivel.credativ.lan <nowiki>Problems with variable cursorname in ecpg</nowiki>]
}}

{{TodoEndSubsection}}

=== libpq ===
{{TodoSubsection}}

{{TodoItem
|Prevent PQfnumber() from lowercasing unquoted column names
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}

{{TodoItem
|Allow statement results to be automatically batched to the client
|Currently all statement results are transferred to the libpq client before libpq makes the results available to the application. This feature would allow the application to make use of the first result rows while the rest are transferred, or held on the server waiting for them to be requested by libpq. One complexity is that a statement like SELECT 1/col could error out mid-way through the result set.}}

{{TodoItem
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]
}}

{{TodoItem
|Add PQexecf() that allows complex parameter substitution
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]
}}

{{TodoItem
|Add SQLSTATE and severity to errors generated within libpq itself
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01425.php
}}

{{TodoItem
|Add support for interface/ipaddress binding to libpq
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php <nowiki>SR/libpq - outbound interface/ipaddress binding</nowiki>]
}}

{{TodoEndSubsection}}

== Triggers ==

{{TodoItem
|Improve storage of deferred trigger queue
|Right now all deferred trigger information is stored in backend memory. This could exhaust memory for very large trigger queues. This item involves dumping large queues into files, or doing some kind of join to process all the triggers, some bulk operation, or a bitmap.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php <nowiki>Scaling up deferred unique checks and the after trigger queue</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00023.php
}}

{{TodoItem
|Allow triggers to be disabled in only the current session.
|This is currently possible by starting a multi-statement transaction, modifying the system tables, performing the desired SQL, restoring the system tables, and committing the transaction. ALTER TABLE ... TRIGGER requires a table lock so it is not ideal for this usage.}}

{{TodoItem
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}

{{TodoItem
|Allow statement-level triggers to access modified rows}}

{{TodoItem
|When statement-level triggers are defined on a parent table, have them fire only on the parent table, and fire child table triggers only where appropriate
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php <nowiki>Statement-level triggers and inheritance</nowiki>]
}}

{{TodoItem
|Allow AFTER triggers on system tables
|System tables are modified in many places in the backend without going through the executor and therefore not causing triggers to fire. To complete this item, the functions that modify system tables will have to fire triggers.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01665.php
* http://wiki.postgresql.org/wiki/DDL_Triggers
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg00022.php
}}

{{TodoItem
|Tighten trigger permission checks
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]
}}

{{TodoItem
|Allow BEFORE INSERT triggers on views
* [http://archives.postgresql.org/pgsql-general/2007-02/msg01466.php <nowiki>Re: Why can't I put a BEFORE EACH ROW trigger on a view?</nowiki>]
}}

{{TodoItem
|Add database and transaction-level triggers
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]
}}

{{TodoItem
|Reduce locking requirements for creating a trigger
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php <nowiki>Re: Change lock requirements for adding a trigger</nowiki>]
}}

{{TodoItem
|Avoid requirement for "AFTER" trigger functions to return a value
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02384.php
}}

{{TodoItem
|Allow creation of inline triggers
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00708.php
}}

== Inheritance ==

{{TodoItem
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys
* [http://archives.postgresql.org/pgsql-hackers/2010-05/msg00285.php <nowiki>Partitioning/inherited tables vs FKs</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00039.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00305.php
}}

{{TodoItem
|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.}}

{{TodoItem
|Determine whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY). If yes, implement it.}}

{{TodoItem
|ALTER TABLE variants sometimes support recursion and sometimes not, but this is poorly/not documented, and the ONLY marker would then be silently ignored. Clarify the documentation, and reject ONLY if it is not supported.}}

== Indexes ==

{{TodoItem
|Prevent index uniqueness checks when UPDATE does not modify the column
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.
However, HOT already short-circuits this in common cases, so more work might not be helpful.}}

{{TodoItem
|Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes
|Such indexes could be more compact if there are only a few distinct values. Such indexes can also be compressed. Keeping such indexes updated can be costly.
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php <nowiki>Bitmap Indexes: request for feedback</nowiki>]
* http://archives.postgresql.org/message-id/800923.27831.qm@web29010.mail.ird.yahoo.com
}}

{{TodoItem
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02179.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00459.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02054.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01731.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00894.php
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00679.php
}}

{{TodoItem
|Consider having a larger statistics target for indexed columns and expression indexes.
}}

{{TodoItem
|Consider smaller indexes that record a range of values per heap page, rather than having one index entry for every heap row
|This is useful if the heap is clustered by the indexed values.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00341.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01264.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00465.php <nowiki>Grouped Index Tuples / Clustered Indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php <nowiki>Bitmapscan changes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php <nowiki>Re: GIT patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php <nowiki>Re: Index Tuple Compression Approach?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php <nowiki>Re: Index AM change proposals, redux</nowiki>]
}}

{{TodoItem
|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.
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]
}}

{{TodoItem
|Allow multiple indexes to be created concurrently, ideally via a single heap scan
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00093.php
}}

{{TodoItem
|Consider sorting entries before inserting into btree index
* [http://archives.postgresql.org/pgsql-general/2008-01/msg01010.php <nowiki>Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?</nowiki>]
}}

{{TodoItem
|Allow index scans to return matching index keys, not just the matching heap locations
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01657.php <nowiki>Re: Is this TODO item done?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01477.php <nowiki>Index-only quals</nowiki>]
}}

{{TodoItem
|Allow creation of an index that can do comparisons to test if a value is between two column values
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00757.php <nowiki>Proposal: temporal extension "period" data type</nowiki>]
}}

{{TodoItem
|Consider using "effective_io_concurrency" for index scans
* Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.
}}

{{TodoItem
|Fix problem with btree page splits during checkpoints
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00052.php
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00184.php
}}

=== GIST ===
{{TodoSubsection}}

{{TodoItem
|Add more GIST index support for geometric data types}}

{{TodoItem
|Allow GIST indexes to create certain complex index types, like digital trees (see Aoki)}}

{{TodoItem
|Fix performance issues in contrib/seg and contrib/cube GiST support
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00069.php <nowiki>Re: GiST index performance</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2009-06/msg00068.php <nowiki>GiST index performance</nowiki>]
}}

{{TodoEndSubsection}}

=== Hash ===
{{TodoSubsection}}

{{TodoItem
|Add UNIQUE capability to hash indexes}}

{{TodoItem
|Add hash WAL logging for crash recovery
* http://archives.postgresql.org/pgsql-performance/2011-09/msg00196.php
}}

{{TodoItem
|Allow multi-column hash indexes}}

{{TodoEndSubsection}}

== Sorting ==

{{TodoItem
|Consider whether duplicate keys should be sorted by block/offset
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]
}}

{{TodoItem
|Consider being smarter about memory and external files used during sorts
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php <nowiki>Re: Sorting Improvements for 8.4</nowiki>]
}}

{{TodoItem
|Consider detoasting keys before sorting}}

{{TodoItem
|Allow sorts to use more available memory
* http://archives.postgresql.org/pgsql-hackers/2007-11/msg01026.php
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01123.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg01957.php
}}

== Fsync ==

{{TodoItem
|Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether fsync does anything
|Ideally this requires a separate test program like /contrib/pg_test_fsync that can be run at initdb time or optionally later.}}

{{TodoItem
|Consider sorting writes during checkpoint
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php <nowiki>Re: Sorting writes during checkpoint</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg02012.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00278.php
* [http://archives.postgresql.org/message-id/CA+TgmoaHu1zuNohoE=cEP0nSc+0wtuRSyEAj_Af2XhxU+ry6-w@mail.gmail.com checkpoint writeback via sync_file_range]
}}

== Cache Usage ==

{{TodoItemDone
|Speed up COUNT(*)
|We could use a fixed row count and a +/- count to follow MVCC visibility rules, or a single cached value could be used and invalidated if anyone modifies the table. Another idea is to get a count directly from a unique index, but for this to be faster than a sequential scan it must avoid access to the heap to obtain tuple visibility information. Note that the index-only scans feature is now implemented which now dramatically speeds up some COUNT(*) cases.
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItem
|Provide a way to calculate an "estimated COUNT(*)"
|Perhaps by using the optimizer's cardinality estimates or random sampling.
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php <nowiki>Re: Improving count(*)</nowiki>]
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItemDone
|Allow data to be pulled directly from indexes
|Currently indexes do not have enough tuple visibility information to allow data to be pulled from the index without also accessing the heap. The idea is to use the visibility map used for vacuum to avoid heap lookups on pages where all tuples are visible.
* [http://wiki.postgresql.org/wiki/Index-only_scans Index-Only Scans wiki]
}}

{{TodoItem
|Consider automatic caching of statements at various levels:
* Parsed query tree
* Query execute plan
* Query results

:
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]
}}

{{TodoItem
|Consider increasing internal areas (NUM_CLOG_BUFFERS) when shared buffers is increased
* [http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php <nowiki>Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php <nowiki>clog_buffers to 64 in 8.3?</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php <nowiki>CLOG Patch</nowiki>]
}}

{{TodoItem
|Consider decreasing the amount of memory used by PrivateRefCount
|
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php <nowiki>PrivateRefCount (for 8.3)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php <nowiki>Re: PrivateRefCount (for 8.3)</nowiki>]
}}

{{TodoItem
|Consider allowing higher priority queries to have referenced buffer cache pages stay in memory longer
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]
}}

== Vacuum ==

{{TodoItem
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]
}}

{{TodoItem
|Allow concurrent inserts to use recently created pages rather than creating new ones
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php
}}

{{TodoItem
|Consider having single-page pruning update the visibility map
* <nowiki>https://commitfest.postgresql.org/action/patch_view?id=75</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php <nowiki>Re: visibility maps and heap_prune</nowiki>]
}}

{{TodoItem
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]
}}

{{TodoItem
|Bias FSM towards returning free space near the beginning of the heap file, in hopes that empty pages at the end can be truncated by VACUUM
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php <nowiki>FSM search modes</nowiki>]
}}

{{TodoItem
|Consider a more compact data representation for dead tuple locations within VACUUM
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php <nowiki>Re: Have vacuum emit a warning when it runs out of maintenance_work_mem</nowiki>]
}}

{{TodoItem
|Provide more information in order to improve user-side estimates of dead space bloat in relations
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]
}}

{{TodoItem
|Improve locking behaviour of vacuum during trailing page truncation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00319.php
* http://archives.postgresql.org/message-id/4D8DF88E.7080205@Yahoo.com
}}

{{TodoItem
|Reduce the number of table scans performed by vacuum
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00605.php
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php
}}

=== Auto-vacuum ===
{{TodoSubsection}}

{{TodoItemEasy
|Issue log message to suggest VACUUM FULL if a table is nearly empty?}}

{{TodoItem
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can do that.
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]
}}

{{TodoItem
|Prevent autovacuum from running if an old transaction is still running from the last vacuum
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]
}}

{{TodoItem
|Have autoanalyze of parent tables occur when child tables are modified
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php
* http://archives.postgresql.org/pgsql-performance/2010-10/msg00271.php
}}

{{TodoItem
|Allow parallel cores to be used by vacuumdb
* [http://archives.postgresql.org/message-id/4F10A728.7090403@agliodbs.com vacuumdb -j]
}}

{{TodoEndSubsection}}

== Locking ==

{{TodoItem
|Fix priority ordering of read and write light-weight locks
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php <nowiki>lwlocks and starvation</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php <nowiki>Re: lwlocks and starvation</nowiki>]
}}

{{TodoItem
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]
}}

{{TodoItem
|Allow UPDATEs on only non-referential integrity columns not to conflict with referential integrity locks
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php <nowiki>Referential Integrity and SHARE locks</nowiki>]
}}

{{TodoItem
|Add idle_in_transaction_timeout GUC so locks are not held for long periods of time}}

{{TodoItem
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]
}}

{{TodoItem
|Detect deadlocks involving LockBufferForCleanup()
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
}}

{{TodoItem
|Allow finer control over who is cancelled in a deadlock
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01727.php
}}

{{TodoItem
|Consider a lock timeout parameter
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00485.php <nowiki>SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5</nowiki>]
}}

{{TodoItem
|Reduce number of unnecessary false positives in Serializable Snapshot Isolation
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00609.php <nowiki>SSI heap_insert and page-level predicate locks</nowiki>]
}}

== Startup Time Improvements ==

{{TodoItem
|Experiment with multi-threaded backend for backend creation
|This would prevent the overhead associated with process creation. Most operating systems have trivial process creation time compared to database startup overhead, but a few operating systems (Win32, Solaris) might benefit from threading. Also explore the idea of a single session using multiple threads to execute a statement faster.}}

{{TodoItem
|Allow backends to change their database without restart
|This allows for faster server startup.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00843.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00336.php
}}

== Write-Ahead Log ==

{{TodoItem
|Eliminate need to write full pages to WAL before page modification
|Currently, to protect against partial disk page writes, we write full page images to WAL before they are modified so we can correct any partial page writes during recovery. These pages can also be eliminated from point-in-time archive files.
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01191.php
* [http://archives.postgresql.org/message-id/20120105061916.GB21048@fetter.org WIP double writes]
* [http://archives.postgresql.org/message-id/4EFC449F02000025000441CD@gw.wicourts.gov double writes]
* [http://archives.postgresql.org/message-id/20120110214344.GB21106@fetter.org Double-write with Fast Checksums]
* [http://archives.postgresql.org/message-id/1962493974.656458.1327703514780.JavaMail.root@zimbra-prod-mbox-4.vmware.com double writes using "double-write buffer" approach]
}}

{{TodoItem
|When full page writes are off, write CRC to WAL and check file system blocks on recovery
|If CRC check fails during recovery, remember the page in case a later CRC for that page properly matches. The difficulty is that hint bits are not WAL logged, meaning a valid page might not match the earlier CRC.}}

{{TodoItem
|Write full pages during file system write and not when the page is modified in the buffer cache
|This allows most full page writes to happen in the background writer. It might cause problems for applying WAL on recovery into a partially-written page, but later the full page will be replaced from WAL.
* [http://archives.postgresql.org/message-id/CAGvK12UST-tPhyLrSLuSpwFxZbAO79yYrhV2xaLmS2MkUxNUVQ@mail.gmail.com Page Checksums + Double Writes]
}}

{{TodoItem
|Reduce WAL traffic so only modified values are written rather than entire rows
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php <nowiki>Reduction in WAL for UPDATEs</nowiki>]
}}

{{TodoItem
|Allow WAL information to recover corrupted pg_controldata
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]
}}

{{TodoItem
|Find a way to reduce rotational delay when repeatedly writing last WAL page
|Currently fsync of WAL requires the disk platter to perform a full rotation to fsync again. One idea is to write the WAL to different offsets that might reduce the rotational delay.
* [http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php <nowiki>500 tpsQL + WAL log implementation</nowiki>]
}}

{{TodoItem
|Speed WAL recovery by allowing more than one page to be prefetched
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay.
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]
}}

{{TodoItem
|Improve WAL concurrency by increasing lock granularity
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]
}}

{{TodoItem
|Be more aggressive about creating WAL files
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php <nowiki>Re: PANIC caused by open_sync on Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-07/msg01075.php <nowiki>PreallocXlogFiles</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2005-04/msg00556.php <nowiki>WAL/PITR additional items</nowiki>]
}}

{{TodoItem
|Have resource managers report the duration of their status changes
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]
}}

{{TodoItem
|Move pgfoundry's xlogdump to /contrib and have it rely more closely on the WAL backend code
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php <nowiki>xlogdump</nowiki>]
}}

{{TodoItem
|Close deleted WAL files held open in *nix by long-lived read-only backends
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]
}}

== Optimizer / Executor ==

{{TodoItem
|Improve selectivity functions for geometric operators}}

{{TodoItem
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]
}}

{{TodoItem
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG}}

{{TodoItem
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}

{{TodoItem
|Consider compressed annealing to search for query plans
|This might replace GEQO.
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us
}}

{{TodoItem
|Improve use of expression indexes for ORDER BY
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php <nowiki>Resjunk sort columns, Heikki's index-only quals patch, and bug #5000</nowiki>]
}}

{{TodoItem
|Modify the planner to better estimate caching effects
* http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php
}}

{{TodoItem
|Allow shared buffer cache contents to affect index cost computations
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php
}}

=== Hashing ===
{{TodoSubsection}}

{{TodoItem
|Consider using a hash for joining to a large IN (VALUES ...) list
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]
}}

{{TodoItem
|Allow single batch hash joins to preserve outer pathkeys
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|"lazy" hash tables - look up only the tuples that are actually requested
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid building the same hash table more than once during the same query
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid hashing for distinct and then re-hashing for hash join
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoEndSubsection}}

== Background Writer ==

{{TodoItem
|Consider having the background writer update the transaction status hint bits before writing out the page
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.}}

{{TodoItem
|Consider adding buffers the background writer finds reusable to the free list
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]
}}

{{TodoItem
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]
}}

{{TodoItem
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]
}}

{{TodoItem
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]
}}

== Concurrent Use of Resources ==

{{TodoItem
|Do async I/O for faster random read-ahead of data
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-09/msg00255.php <nowiki>Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-01/msg00170.php <nowiki>Bitmap index scan preread using posix_fadvise (Was: There's random access and then there's random access)</nowiki>]
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]
}}

{{TodoItem
|Experiment with multi-threaded backend for better I/O utilization
|This would allow a single query to make use of multiple I/O channels simultaneously. One idea is to create a background reader that can pre-fetch sequential and index scan pages needed by other backends. This could be expanded to allow concurrent reads from multiple devices in a partitioned table.
* http://archives.postgresql.org/pgsql-performance/2011-02/msg00123.php
}}

{{TodoItem
|Experiment with multi-threaded backend for better CPU utilization
|This would allow several CPUs to be used for a single query, such as for sorting or query execution.
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00945.php <nowiki>Multi CPU Queries - Feedback and/or suggestions wanted!</nowiki>]
}}

{{TodoItem
|SMP scalability improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

== TOAST ==

{{TodoItem
|Allow user configuration of TOAST thresholds
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]
}}

{{TodoItem
|Reduce unnecessary cases of deTOASTing
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]
}}

{{TodoItem
|Reduce costs of repeat de-TOASTing of values
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]
}}

== Monitoring ==
{{TodoItem
|Expand pg_stat_activity for easier integration with monitoring tools
|* http://archives.postgresql.org/message-id/4DFA13A5.2060200@2ndQuadrant.com
}}

{{TodoItem
|Add column to pg_stat_activity that shows the progress of long-running commands like CREATE INDEX and VACUUM
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00203.php <nowiki>EXPLAIN progress info</nowiki>]
* The CLUSTER/VACUUM FULL implementation would also be useful to track this way
}}

{{TodoItem
|Have pg_stat_activity display query strings in the correct client encoding
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php <nowiki>pg_stats queries versus per-database encodings</nowiki>]
}}

{{TodoItemEasy
|Expose pg_controldata via an SQL interface
|Helpful for monitoring replicated databases
* http://archives.postgresql.org/message-id/4B901D73.8030003@agliodbs.com
* [http://archives.postgresql.org/message-id/4B959D7A.6010907@joeconway.com initial patch]
}}

== Miscellaneous Performance ==

{{TodoItem
|Use mmap() rather than SYSV for shared buffers?
|This would remove the requirement for SYSV SHM but would introduce portability issues. Anonymous mmap (or mmap to /dev/zero) is required to prevent I/O overhead. We could also consider mmap() for writing WAL.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00750.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00756.php
}}

{{TodoItem
|Rather than consider mmap()-ing in 8k pages, consider mmap()'ing entire files into a backend?
|Doing I/O to large tables would consume a lot of address space or require frequent mapping/unmapping. Extending the file also causes mapping problems that might require mapping only individual pages, leading to thousands of mappings. Another problem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk before WAL is written.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01239.php
}}

{{TodoItem
|Consider ways of storing rows more compactly on disk:
* Reduce the row header size?
* Consider reducing on-disk varlena length from four bytes to two because a heap row cannot be more than 64k in length}}

{{TodoItem
|Consider transaction start/end performance improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php <nowiki>Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

{{TodoItem
|Allow configuration of backend priorities via the operating system
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]
}}

{{TodoItem
|Consider increasing the minimum allowed number of shared buffers
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]
}}

{{TodoItem
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]
}}

{{TodoItem
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]
}}

{{TodoItem
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]
}}

{{TodoItem
|Sort large UPDATE/DELETEs so it is done in heap order
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]
}}

{{TodoItemDone
|Allow one transaction to see tuples using the snapshot of another transaction
|This would assist multiple backends in working together.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php <nowiki>Transaction Snapshot Cloning</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00260.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00466.php
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00684.php
}}

{{TodoItem
|Consider decreasing the I/O caused by updating tuple hint bits
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php
}}

{{TodoItem
|Avoid the requirement of freezing pages that are infrequently modified
|If all rows on a page are visible, it is possible to set a bit in the visibility map (once the visibility map is 100% reliable) and not need to freeze the page, avoiding a page rewrite
* http://archives.postgresql.org/message-id/4BF701CF.2090205@agliodbs.com
* http://archives.postgresql.org/pgsql-hackers/2010-06/msg00082.php
}}

{{TodoItem
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]
}}

{{TodoItem
|Restructure truncation logic to be more resistant to failure
|This also involves not writing dirty buffers for a truncated or dropped relation
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php
}}

{{TodoItem
|Consider adding logic to increase large tables by more than 8k
|This would reduce file system fragmentation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00337.php
}}

== Miscellaneous Other ==

{{TodoItem
|Deal with encoding issues for filenames in the server filesystem
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}
}}

{{TodoItem
|Deal with encoding issues in the output of localeconv()
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]
}}

{{TodoItem
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg00846.php <nowiki>patch - Report the schema along table name in a referential failure error message</nowiki>]
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]
}}

{{TodoItemEasy
| Provide [http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html#LIBPQ-CONNECT-FALLBACK-APPLICATION-NAME fallback_application_name] in contrib/pgbench, oid2name, and dblink.
* {{MessageLink|w2g9837222c1004070216u3bc46b3ahbddfdffdbfb46212@mail.gmail.com|fallback_application_name and pgbench}}
}}

{{TodoItem
|Add 64-bit support to /contrib/pgbench
* http://archives.postgresql.org/pgsql-hackers/2010-07/msg00153.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00705.php
}}

== Source Code ==

{{TodoItem
|Add use of 'const' for variables in source tree
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00473.php
}}

{{TodoItemEasy
|Remove warnings created by -Wcast-align}}

{{TodoItem
|Move platform-specific ps status display info from ps_status.c to ports}}

{{TodoItem
|Add optional CRC checksum to heap and index pages
|One difficulty is how to prevent hint bit changes from affecting the computed CRC checksum.
* http://archives.postgresql.org/message-id/19934.1226601952%40sss.pgh.pa.us
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00002.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01028.php <nowiki>double-buffering page writes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00524.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01101.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00011.php <nowiki>Re: Block-level CRC checks</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00249.php
* http://archives.postgresql.org/message-id/20111221215913.GA4536@fetter.org
* http://archives.postgresql.org/message-id/CA+U5nMJzQyxcObkpNAf1SYTX-gO_Mom3O9JXHnGpxRo1kXJ7ww@mail.gmail.com
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00128.php
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00113.php
}}

{{TodoItem
|Consider a faster CRC32 algorithm
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php
}}

{{TodoItem
|Allow cross-compiling by generating the zic database on the target system}}

{{TodoItem
|Improve NLS maintenance of libpgport messages linked onto applications}}

{{TodoItem
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}

{{TodoItem
|Allow creation of universal binaries for Darwin
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]
}}

{{TodoItem
|Consider GnuTLS if OpenSSL license becomes a problem
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]
}}

{{TodoItem
|Consider making NAMEDATALEN more configurable in future releases}}

{{TodoItem
|Research use of signals and sleep wake ups
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]
}}

{{TodoItem
|Allow C++ code to more easily access backend code
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]
}}

{{TodoItem
|Consider simplifying how memory context resets handle child contexts
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]
}}

{{TodoItem
|Create three versions of libpgport to simplify client code
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]
}}

{{TodoItem
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]
}}

{{TodoItem
|Implement the non-threaded Avahi service discovery protocol
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]
}}

{{TodoItem
|Reduce data row alignment requirements on some 64-bit systems
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]
}}

{{TodoItem
|Restructure TOAST internal storage format for greater flexibility
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]
}}

{{TodoItem
| Add regression tests for pg_dump/restore
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01967.php <nowiki>"make install-check-pg_dump" target in src/regress]</nowiki>]
}}

{{TodoItem
| Research different memory allocation methods for lists
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php
}}

{{TodoItem
| Consider removing the attribute options cache
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00039.php
}}

{{TodoItem
| Restructure /contrib section
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00705.php
}}

=== /contrib/pg_upgrade ===
{{TodoSubsection}}

{{TodoItem
|Handle large object comments
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.
}}

{{TodoItem
|Consider using pg_depend for checking object usage in version.c
}}

{{TodoItem
|If reindex is necessary, allow it to be done in parallel with pg_dump custom format
}}

{{TodoItem
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary
|pg_class.oid is not preserved so schema.tablename must be used.
}}

{{TodoItem
|Improve testing, perhaps using the buildfarm
|The buildfarm has access to multiple versions of PostgreSQL.
}}

{{TodoItem
|Create machine-readable output of pg_controldata
|This would avoid parsing its output. The problem is we need pg_controldata output from both the old and new clusters so we would need to support both formats.
}}

{{TodoEndSubsection}}

=== Windows ===
{{TodoSubsection}}

{{TodoItem
|Remove configure.in check for link failure when cause is found}}

{{TodoItem
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}

{{TodoItem
|Allow psql to use readline once non-US code pages work with backslashes}}

{{TodoItem
|Fix problem with shared memory on the Win32 Terminal Server}}

{{TodoItem
|Improve signal handling
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]
}}

{{TodoItem
|Convert MSVC build system to remove most batch files
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]
}}

{{TodoItem
|Support pgxs when using MSVC}}

{{TodoItem
|Fix MSVC NLS support, like for to_char()
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php <nowiki>Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)</nowiki>]
}}

{{TodoItem
|Find a correct rint() substitute on Windows
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]
}}

{{TodoItem
|Fix global namespace issues when using multiple terminal server sessions
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}

{{TodoItem
|Change from the current autoconf/gmake build system to cmake
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01869.php <nowiki>About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)</nowiki>]
}}

{{TodoItem
|Improve consistency of path separator usage
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net
}}

{{TodoItem
|Fix cross-compiling on Windows
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php
}}

{{TodoItemDone
|Allow multiple Postgres clusters running on the same machine to distinguish themselves in the event log
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01297.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00574.php
}}

{{TodoEndSubsection}}

=== Wire Protocol Changes ===
{{TodoSubsection}}

{{TodoItem
|Allow dynamic character set handling}}

{{TodoItem
|Add decoded type, length, precision}}

{{TodoItem
|Mark result columns as known-not-null when possible
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]
}}

{{TodoItem
|Provide more control over planner treatment of statements being prepared}}

{{TodoItem
|Use compression?}}

{{TodoItem
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}

{{TodoItem
|Set protocol for wire format negotiation
* [http://archives.postgresql.org/message-id/CACMqXCKkGrGXxQhjHCKCe0B8hn6sTt-1sdgHZOSGQMxrusOsQA@mail.gmail.com GUC_REPORT for protocol tunables]
}}

{{TodoItem
|Make sure upgrading to a 4.1 protocol version will actually work smoothly
* [http://archives.postgresql.org/message-id/28307.1318255008@sss.pgh.pa.us Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable]
}}

{{TodoEndSubsection}}

== Documentation ==

{{TodoItem
|Convert single quotes to apostrophes in the PDF documentation
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]
}}

{{TodoItem
|Provide a manpage for postgresql.conf
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Consider changing documentation format from SGML to XML
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]
* http://archives.postgresql.org/pgsql-docs/2011-04/msg00020.php
* http://wiki.postgresql.org/wiki/Switching_PostgreSQL_documentation_from_SGML_to_XML
}}

{{TodoItem
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com
}}

{{TodoItem
|Add diagrams to the documentation
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php
}}

== Exotic Features ==

{{TodoItem
|Add pre-parsing phase that converts non-ISO syntax to supported syntax
|This could allow SQL written for other databases to run without modification.}}

{{TodoItem
|Allow plug-in modules to emulate features from other databases}}

{{TodoItem
|Add features of Oracle-style packages
|A package would be a schema with session-local variables, public/private functions, and initialization functions. It is also possible to implement these capabilities in any schema and not use a separate "packages" syntax at all.
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]
}}

{{TodoItem
|Consider allowing control of upper/lower case folding of unquoted identifiers
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00849.php <nowiki>TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
}}

{{TodoItem
|Add autonomous transactions
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]
}}

{{TodoItem
|Give query progress indication
* [[Query progress indication]]
}}

{{TodoItem
|Rethink our type system
* [[Rethinking datatypes]]
}}

== Features We Do ''Not'' Want ==

The following features have been discussed ad nauseum on the PostgreSQL mailing lists and the consensus has been that the project is not interested in them. As such, if you are going to bring them up as potential features, you will want to be familiar with all of the arguments against these features which have been previously made over the years. If you decide to work on such features anyway, you should be aware that you face a higher-than-normal barrier to get the Project to accept them.

{{TodoItem
|All backends running as threads in a single process (not wanted)
|This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. Threading specific operations such as I/O, seq scans, and connection management has been discussed and will probably be implemented to enable specific performance features. Moving to a threaded engine would also require halting all other work on PostgreSQL for one to two years.}}

{{TodoItem
|"Oracle-style" optimizer hints (not wanted)
|Optimizer hints, as implemented in Oracle and other RDBMSes, are used to work around problems in the optimizer and introduce upgrade and maintenance issues. We would rather have such problems reported and fixed. We have discussed a more sophisticated system of per-class cost adjustment instead, but a specification remains to be developed. See [[OptimizerHintsDiscussion|Optimizer Hints Discussion]] for further information.}}

{{TodoItem
|Embedded server (not wanted)
|While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliably and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases. Besides, there are several very mature embedded SQL databases already available.}}

{{TodoItem
|Obfuscated function source code (not wanted)
|Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]
}}

{{TodoItem
|Indeterminate behavior for the GROUP BY clause (not wanted)
|At least one other database product allows specification of a subset of the result columns which GROUP BY would need to be able to provide predictable results; the server is free to return any value from the group. This is not viewed as a desirable feature. PostgreSQL 9.1 allows result columns that are not referenced by GROUP BY if a primary key for the same table is referenced in GROUP BY.
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]
}}

</div>

[[Category:Todo]]

Todo

2012-01-16T18:28:04Z

Petere: /* ALTER */ add missing rename support items

<div style="margin: 1ex 1em; float: right;">
__TOC__
</div>

This list contains '''all known PostgreSQL bugs and feature requests'''. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].

* {{TodoPending}} - marks ordinary, incomplete items
* {{TodoEasy}} - marks items that are easier to implement
* {{TodoDone}} - marks changes that are done, and will appear in the PostgreSQL 9.2 release.

For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the mailing list.</b>

<div style="padding: 1ex 4em;">
== Administration ==

{{TodoItem
|Allow administrators to cancel multi-statement idle transactions
|This allows locks to be released, but it is complex to report the cancellation back to the client.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php <nowiki>Cancelling idle in transaction state</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00441.php <nowiki>Re: Cancelling idle in transaction state</nowiki>]
}}

{{TodoItem
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]
}}

{{TodoItem
|Set proper permissions on non-system schemas during db creation
|Currently all schemas are owned by the super-user because they are copied from the template1 database. However, since all objects are inherited from the template database, it is not clear that setting schemas to the db owner is correct.}}

{{TodoItem
|Allow log_min_messages to be specified on a per-module basis
|This would allow administrators to see more detailed information from specific sections of the backend, e.g. checkpoints, autovacuum, etc. Another idea is to allow separate configuration files for each module, or allow arbitrary SET commands to be passed to them. See also [[Logging Brainstorm]].}}

{{TodoItem
|Simplify creation of partitioned tables
|This would allow creation of partitioned tables without requiring creation of triggers or rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. See also [[Table partitioning]]
}}

{{TodoItem
|Allow custom variables to appear in pg_settings()
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]
}}

{{TodoItem
|Have custom variables be transaction-safe
* {{MessageLink|4B577E9F.8000505@dunslane.net|Custom GUCs still a bit broken}}
}}

{{TodoItem
|Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]
}}

{{TodoItem
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]
}}

{{TodoItem
|Provide a way to query the log collector subprocess to determine the name of the currently active log file
* [http://archives.postgresql.org/pgsql-general/2008-11/msg00418.php <nowiki>Current log files when rotating?</nowiki>]
}}

{{TodoItem
|Allow simpler reporting of the unix domain socket directory and allow easier configuration of its default location
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01555.php
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01482.php
}}

{{TodoItem
|Allow custom daemons to be automatically stopped/started along with the postmaster
|This allows easier administration of daemons like user job schedulers or replication-related daemons.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01701.php <nowiki>Re: scheduler in core</nowiki>]
}}

{{TodoItem
|Improve logging of prepared transactions recovered during startup
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>"recovering prepared transaction" after server restart message</nowiki>]
}}

{{TodoItem
|Consider using POSIX shared memory to avoid System V shared memory kernel limits
* [http://archives.postgresql.org/message-id/4DFA2673.3010009@enterprisedb.com <nowiki>POSIX shared memory patch status</nowiki>]
}}

{{TodoItemDone
|Address problem where superusers are assumed to be members of all groups
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
}}

=== Configuration files ===
{{TodoSubsection}}

{{TodoItemEasy
|Change pg_ident.conf parsing to be the same as pg_hba.conf
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg02204.php
}}

{{TodoItem
|Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00764.php
}}

{{TodoItem
|Consider normalizing fractions in postgresql.conf, perhaps using '%'
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]
}}

{{TodoItem
|Allow Kerberos to disable stripping of realms so we can check the username@realm against multiple realms
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php <nowiki>krb_match_realm patch</nowiki>]
}}

{{TodoItem
|Improve LDAP authentication configuration options
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php <nowiki>Proposed Patch - LDAPS support for servers on port 636 w/o TLS</nowiki>]
}}

{{TodoItem
|Add external tool to auto-tune some postgresql.conf parameters
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php <nowiki>Simple postgresql.conf wizard</nowiki>]
}}

{{TodoItem
|Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php <nowiki>Re: Plans for 8.4</nowiki>]
}}

{{TodoItem
|Process pg_hba.conf keywords as case-insensitive
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00432.php <nowiki>More robust pg_hba.conf parsing/error logging</nowiki>]
}}

{{TodoItem
|Create utility to compute accurate random_page_cost value
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00162.php
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00362.php
}}

{{TodoItem
|Allow configuration files to be independently validated
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php
* http://archives.postgresql.org/message-id/12666.1310774573@sss.pgh.pa.us
}}

{{TodoItem
|Allow postgresql.conf settings to be accepted by backends even if some settings are invalid for those backends
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoItem
|Allow all backends to receive postgresql.conf setting changes at the same time
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoEndSubsection}}

=== Tablespaces ===
{{TodoSubsection}}

{{TodoItem
|Allow a database in tablespace t1 with tables created in tablespace t2 to be used as a template for a new database created with default tablespace t2
|Currently all objects in the default database tablespace must have default tablespace specifications. This is because new databases are created by copying directories. If you mix default tablespace tables and tablespace-specified tables in the same directory, creating a new database from such a mixed directory would create a new database with tables that had incorrect explicit tablespaces. To fix this would require modifying pg_class in the newly copied database, which we don't currently do.}}

{{TodoItem
|Allow reporting of which objects are in which tablespaces
|This item is difficult because a tablespace can contain objects from multiple databases. There is a server-side function that returns the databases which use a specific tablespace, so this requires a tool that will call that function and connect to each database to find the objects in each database for that tablespace.}}

{{TodoItem
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original}}

{{TodoItem
|Allow per-tablespace quotas}}

{{TodoItem
|Allow tablespaces on RAM-based partitions for unlogged tables
* http://archives.postgresql.org/pgsql-advocacy/2011-05/msg00033.php
}}

{{TodoItem
|Allow toast tables to be moved to a different tablespace
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00980.php
* {{messageLink|CAFEQCbH756DyyAPQ1ykh3+b+kE1-EhWRww1WO_x5v38C-uLnUg@mail.gmail.com|patch : Allow toast tables to be moved to a different tablespace}} (issues remain)
}}

{{TodoEndSubsection}}

=== Statistics Collector ===
{{TodoSubsection}}

{{TodoItem
|Allow statistics last vacuum/analyze execution times to be displayed without requiring track_counts to be enabled
* [http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php <nowiki>row-level stats and last analyze time</nowiki>]
}}

{{TodoItem
|Clear table counters on TRUNCATE
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php <nowiki>Small TRUNCATE glitch</nowiki>]
}}

{{TodoEndSubsection}}

=== SSL ===
{{TodoSubsection}}

{{TodoItem
|Allow SSL authentication/encryption over unix domain sockets
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00924.php <nowiki>Re: Spoofing as the postmaster</nowiki>]
}}

{{TodoItem
|Allow SSL key file permission checks to be optionally disabled when sharing SSL keys with other applications
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php <nowiki>BUG #3809: SSL "unsafe" private key permissions bug</nowiki>]
}}

{{TodoItem
|Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart
|Unlike SSL CRT files, CRL (Certificate Revocation List) files are updated frequently
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00832.php <nowiki>Automatic CRL reload</nowiki>]
Alternatively or additionally supporting OCSP (online certificate security protocol) would provide real-time revocation discovery without reloading
}}

{{TodoItem
| Allow automatic selection of SSL client certificates from a certificate store
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]
}}

{{TodoItem
| Send the full certificate server chain to the client
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]
}}

{{TodoEndSubsection}}

=== Point-In-Time Recovery (PITR) ===
{{TodoSubsection}}

{{TodoItemEasy
|Create dump tool for write-ahead logs for use in determining transaction id for point-in-time recovery
|This is useful for checking PITR recovery.}}

{{TodoItem
|Allow archive_mode to be changed without server restart?
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php <nowiki>Enabling archive_mode without restart</nowiki>]
}}

{{TodoItem
|Consider avoiding WAL switching via archive_timeout if there has been no database activity
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01469.php <nowiki>archive_timeout behavior for no activity</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg00395.php <nowiki>Re: archive_timeout behavior for no activity</nowiki>]
}}

{{TodoEndSubsection}}

=== Standby server mode ===
{{TodoSubsection}}

{{TodoItem
| Allow pg_xlogfile_name() to be used in recovery mode
* [http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12@mail.gmail.com <nowiki>Streaming replication and pg_xlogfile_name()</nowiki>]
}}

{{TodoItem
| Prevent variables inherited from the server environment from begin used for making streaming replication connections.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01011.php <nowiki>Re: Parameter name standby_mode</nowiki>]
}}

{{TodoItemDone
| Allow hot file system backups on standby servers
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01727.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
}}

{{TodoItem
| Change walsender so that it applies per-role settings
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00642.php
}}

{{TodoItem
| Add more control over waiting for synchronous commit
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01611.php
}}

{{TodoItem
| Restructure configuration parameters for standby mode
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01820.php
}}

{{TodoItem
| Allow time-delayed application of logs on the standby
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00992.php
}}
{{TodoItem
| Add -X parameter to pg_basebackup to specify a different directory for px_xlog, like initdb
}}

{{TodoEndSubsection}}

== Data Types ==

{{TodoItem
|Fix data types where equality comparison is not intuitive, e.g. box
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01643.php
}}

{{TodoItem
|Add support for public SYNONYMs
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php
* http://archives.postgresql.org/pgsql-general/2010-12/msg00139.php
}}

{{TodoItem
|Add support for SQL-standard GENERATED/IDENTITY columns
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]
}}

{{TodoItem
|Consider placing all sequences in a single table, or create a system view
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItem
|Consider a special data type for regular expressions
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]
}}

{{TodoItem
|Reduce BIT data type overhead using short varlena headers
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php <nowiki>storage size of "bit" data type..</nowiki>]
}}

{{TodoItem
|Allow renaming and deleting enumerated values from an existing enumerated data type
}}

{{TodoItem
|Support scoped IPv6 addresses in the inet type
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php <nowiki>strange problem with ip6</nowiki>]
}}

{{TodoItem
|Add a JSON (JavaScript Object Notation) data type
|This would behave similar to the XML data type, which is stored as text, but allows element lookup and conversion functions.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01494.php <nowiki>PATCH: Add hstore_to_json()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg00001.php <nowiki>Re: PATCH: Add hstore_to_json()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg01092.php <nowiki>Proposal: Add JSON support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00057.php <nowiki>Re: Proposal: Add JSON support</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00481.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01694.php
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg00219.php
}}

{{TodoItem
|Considering improving performance of computing CHAR() value lengths
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00900.php <nowiki>char() overhead on read-only workloads not so insignifcant as the docs claim it is...</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01787.php <nowiki>Re: [PATCH] backend: compare word-at-a-time in bcTruelen</nowiki>]
}}

{{TodoItem
|Add overlaps geometric operators that ignore point overlaps
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00861.php
}}

{{TodoItem
| Add IMMUTABLE column attribute
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00623.php
}}

=== Domains ===
{{TodoSubsection}}

{{TodoItem
|Allow functions defined as casts to domains to be called during casting
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]
}}

{{TodoItem
|Allow values to be cast to domain types
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00812.php
}}

{{TodoItem
|Make domains work better with polymorphic functions
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]
}}

{{TodoEndSubsection}}

=== Dates and Times ===
{{TodoSubsection}}

{{TodoItem
|Allow infinite intervals just like infinite timestamps
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00076.php
}}

{{TodoItem
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules.
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]
}}

{{TodoItem
|Have timestamp subtraction not call justify_hours()?
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]
}}

{{TodoItem
|Improve TIMESTAMP WITH TIME ZONE subtraction to be DST-aware
|Currently subtracting one date from another that crosses a daylight savings time adjustment can return '1 day 1 hour', but adding that back to the first date returns a time one hour in the future. This is caused by the adjustment of '25 hours' to '1 day 1 hour', and '1 day' is the same time the next day, even if daylight savings adjustments are involved.}}

{{TodoItem
|Fix interval display to support values exceeding 2^31 hours}}

{{TodoItem
|Add overflow checking to timestamp and interval arithmetic}}

{{TodoItem
|Add function to allow the creation of timestamps using parameters
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00232.php
}}

{{TodoEndSubsection}}

=== Arrays ===
{{TodoSubsection}}

{{TodoItem
|Add support for arrays of domains
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php <nowiki>Re: updated WIP: arrays of composites</nowiki>]
}}

{{TodoItem
|Allow single-byte header storage for array elements}}

{{TodoItem
|Add function to detect if an array is empty
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php <nowiki>Re: array_length()</nowiki>]
}}

{{TodoItem
|Improve handling of empty arrays
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php <nowiki>So what's an "empty" array anyway?</nowiki>]
}}

{{TodoItem
|Improve handling of NULLs in arrays
* [http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php <nowiki>BUG #4509: array_cat's null behaviour is inconsistent</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php
}}

{{TodoEndSubsection}}

=== Binary Data ===
{{TodoSubsection}}

{{TodoItem
|Improve vacuum of large objects, like contrib/vacuumlo?}}

{{TodoItem
|Auto-delete large objects when referencing row is deleted
|contrib/lo offers this functionality.}}

{{TodoItem
|Allow read/write into TOAST values like large objects
|Writing might require the TOAST column to be stored EXTERNAL.
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00049.php
}}

{{TodoItem
|Add API for 64-bit large object access
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00781.php <nowiki>64-bit API for large objects</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01790.php
}}

{{TodoEndSubsection}}

=== MONEY Data Type ===
{{TodoSubsection}}

{{TodoItem
|Add locale-aware MONEY type, and support multiple currencies
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]
}}

{{TodoItem
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}

{{TodoEndSubsection}}

=== Text Search ===
{{TodoSubsection}}

{{TodoItem
|Allow dictionaries to change the token that is passed on to later dictionaries
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]
}}

{{TodoItem
|Consider a function-based API for '@@' searches
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Simplifying Text Search</nowiki>]
}}

{{TodoItem
|Improve text search error messages
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php <nowiki>Re: Poorly designed tsearch NOTICEs</nowiki>]
}}

{{TodoItem
|Consider changing error to warning for strings larger than one megabyte
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00062.php <nowiki>Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
}}

{{TodoItem
|tsearch and tsdicts regression tests fail in Turkish locale on glibc
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]
}}

{{TodoItem
|tsquery negator operator treated as part of lexeme
* [http://archives.postgresql.org/pgsql-bugs/2009-06/msg00346.php BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation]
}}

{{TodoItem
|Improve handling of plus signs in email address user names, and perhaps improve URL parsing
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00772.php
}}

{{TodoItem
|Improve default parser, to more easily allow adding new tokens
* http://archives.postgresql.org/message-id/23485.1297727826@sss.pgh.pa.us
}}

{{TodoItem
|Add additional support functions
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00319.php
}}

{{TodoEndSubsection}}

=== XML ===
{{TodoSubsection}}

{{TodoItem
|Allow XML arrays to be cast to other data types
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
}}

{{TodoItem
|Add XML Schema validation and xmlvalidate functions (SQL:2008)}}

{{TodoItem
|Add xmlvalidatedtd variant to support validating against a DTD?}}

{{TodoItem
|Relax-NG validation; libxml2 supports this already}}

{{TodoItem
|Allow reliable XML operation non-UTF8 server encodings (xpath(), in particular, is known to not work)
* [http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php <nowiki>BUG #4622: xpath only work in utf-8 server encoding</nowiki>]
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}

{{TodoItem
|Add functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}

{{TodoItem
|Add XMLNAMESPACES support in XMLELEMENT and elsewhere}}

{{TodoItem
|Move XSLT from contrib/xml2 to a more reasonable location
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00539.php
}}

{{TodoItem
|Report errors returned by the XSLT library
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00562.php
}}

{{TodoItem
|Improve the XSLT parameter passing API
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00416.php
}}

{{TodoItem
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}

{{TodoItem
|Add pretty-printed XML output option
|Parse a document and serialize it back in some indented form. libxml2 might support this.}}

{{TodoItem
|Add XMLQUERY (from the SQL/XML standard)}}

{{TodoItem
|Allow XML sthredding
|In some cases shredding could be better option (if there is no need to keep XML docs entirely, e.g. if we have already developed tools that understand only relational data. This would be a separate module that implements annotated schema decomposition technique, similar to DB2 and SQL Server functionality.}}

{{TodoItem
|Fix Nested or repeated xpath() that apparently mess up namespaces [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00097.php] [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00144.php] [http://archives.postgresql.org/pgsql-general/2008-03/msg00295.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/message-id/004f01c90e91$138e9d10$3aabd730$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|XPath: Adding the <x> at the root causes problems [http://archives.postgresql.org/pgsql-bugs/2008-05/msg00184.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/pgsql-general/2008-07/msg00613.php]}}

{{TodoItem
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}

{{TodoItem
|xpath_table is pretty broken anyway [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php]}}

{{TodoItem
|better handling of XPath data types [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php] [http://archives.postgresql.org/message-id/004a01c90e90$4b986d90$e2c948b0$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|Improve handling of PIs and DTDs in xmlconcat() [http://archives.postgresql.org/message-id/200904211211.n3LCB09p008988@wwwmaster.postgresql.org]}}

{{TodoItem
|Restructure XML and /contrib/xml2 functionality
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02314.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00017.php
}}

{{TodoEndSubsection}}

== Functions ==

{{TodoItem
|Allow INET subnet comparisons using non-constants to be indexed}}

{{TodoItem
|Add an INET overlaps operator, for use by exclusion constraints
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00845.php
}}

{{TodoItem
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php <nowiki>RFC for adding typmods to functions</nowiki>]
}}

{{TodoItem
|Fix IS OF so it matches the ISO specification, and add documentation
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]
}}

{{TodoItem
|Implement Boyer-Moore searching in LIKE queries
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}
}}

{{TodoItem
|Prevent malicious functions from being executed with the permissions of unsuspecting users
|Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]
}}

{{TodoItem
|Reduce memory usage of aggregates in set returning functions
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]
}}

{{TodoItem
|Fix /contrib/ltree operator
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]
}}

{{TodoItem
|Fix /contrib/btree_gist's implementation of inet indexing
* [http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php <nowiki>BUG #5705: btree_gist: Index on inet changes query result</nowiki>]
}}

{{TodoItem
|<nowiki>Fix inconsistent precedence of =, >, and < compared to <>, >=, and <=</nowiki>
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php <nowiki>BUG #3822: Nonstandard precedence for comparison operators</nowiki>]
}}

{{TodoItem
|Fix regular expression bug when using complex back-references
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php <nowiki>BUG #3645: regular expression back references seem broken</nowiki>]
}}

{{TodoItem
|Have /contrib/dblink reuse unnamed connections
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php <nowiki>dblink un-named connection doesn't get re-used</nowiki>]
}}

{{TodoItem
|Improve formatting of pg_get_viewdef() output
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01648.php <nowiki>pg_get_viewdef formattiing</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01885.php <nowiki>Re: pretty print viewdefs</nowiki>]
}}

{{TodoItem
|Add function to dump pg_depend information cleanly
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00226.php <nowiki>Elementary dependency look-up</nowiki>]
}}

{{TodoItem
|Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation
* [http://archives.postgresql.org/message-id/28488.1286461610@sss.pgh.pa.us pg_relation_size / could not open relation with OID #]
}}

=== Character Formatting ===

{{TodoSubsection}}
{{TodoItem
|Allow to_date() and to_timestamp() to accept localized month names}}

{{TodoItem
|Add missing parameter handling in to_char()
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]
}}

{{TodoItem
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]
}}

{{TodoItem
|Allow to_char() on interval values to accumulate the highest unit requested
|2= Some special format flag would be required to request such accumulation. Such functionality could also be added to EXTRACT. Prevent accumulation that crosses the month/day boundary because of the uneven number of days in a month.
* to_char(INTERVAL '1 hour 5 minutes', 'MI') => 65
* to_char(INTERVAL '43 hours 20 minutes', 'MI' ) => 2600
* to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') => 0:1:19:20
* to_char(INTERVAL '3 years 5 months','MM') => 41
}}

{{TodoItem
|Fix to_number() handling for values not matching the format string
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php <nowiki>Re: numeric_to_number() function skipping some digits</nowiki>]
}}

{{TodoEndSubsection}}

== Multi-Language Support ==

{{TodoItem
|Add NCHAR (as distinguished from ordinary varchar),}}

{{TodoItem
|Add a cares-about-collation column to pg_proc, so that unresolved-collation errors can be thrown at parse time
* [http://archives.postgresql.org/pgsql-hackers/2011-03/msg01520.php <nowiki>Open issues for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with text search configurations
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with to_char() and related functions
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Support collation-sensitive equality and hashing functions
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00472.php <nowiki> contrib/citext versus collations</nowiki>]
}}

{{TodoItem
|Add a LOCALE option to CREATE DATABASE, as a shorthand
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]
}}

{{TodoItem
|Support multiple simultaneous character sets, per SQL:2008}}

{{TodoItem
|Improve UTF8 combined character handling?}}

{{TodoItem
|Add octet_length_server() and octet_length_client()}}

{{TodoItem
|Make octet_length_client() the same as octet_length()?}}

{{TodoItem
|Fix problems with wrong runtime encoding conversion for NLS message files}}

{{TodoItem
|Add URL to more complete multi-byte regression tests
* [http://archives.postgresql.org/pgsql-hackers/2005-07/msg00272.php <nowiki>Multi-byte and client side character encoding tests for copy command..</nowiki>]
}}

{{TodoItem
|Fix contrib/fuzzystrmatch to work with multibyte encodings
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00138.php <nowiki> dmetaphone woes</nowiki>]
}}

{{TodoItem
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions
|Currently we preallocate memory based on worst-case usage.}}

{{TodoItem
|Add ability to use case-insensitive regular expressions on multi-byte characters
|Currently it works for UTF-8, but not other multi-byte encodings
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php <nowiki>Regexps vs. locale</nowiki>]
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}
}}

{{TodoItem
|Improve encoding of connection startup messages sent to the client
|Currently some authentication error messages are sent in the server encoding
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php <nowiki>encoding of PostgreSQL messages</nowiki>]
* [http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php <nowiki>Re: encoding of PostgreSQL messages</nowiki>]
}}

{{TodoItem
|More sensible support for Unicode combining characters, normal forms
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net
}}

== Views / Rules ==

{{TodoItem
|Automatically create rules on views so they are updateable, per SQL:2008
|We can only auto-create rules for simple views. For more complex cases users will still have to write rules manually.
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php <nowiki>Proposal for updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-08/msg00255.php <nowiki>Updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php <nowiki>Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle</nowiki>]
* http://wiki.postgresql.org/wiki/Updatable_views
}}

{{TodoItem
|Add the functionality of the WITH CHECK OPTION clause to CREATE VIEW}}

{{TodoItem
|Allow VIEW/RULE recompilation when the underlying tables change
|This is both difficult and controversial.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
}}

{{TodoItem
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]
}}

{{TodoItem
|Add the ability to automatically create materialized views
|Right now materialized views require the user to create triggers on the main table to keep the summary table current. SQL syntax should be able to manage the triggers and summary table automatically. A more sophisticated implementation would automatically retrieve from the summary table when the main table is referenced, if possible. See [[Materialized Views]] for implementation details
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00479.php <nowiki>GSoC - proposal - Materialized Views in PostgreSQL</nowiki>]
}}

{{TodoItem
|Improve ability to modify views via ALTER TABLE
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]
}}

{{TodoItem
|Prevent low-cost functions from seeing unauthorized view rows
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg01346.php <nowiki>Using views for row-level access control is leaky</nowiki>]
}}

== SQL Commands ==

{{TodoItem
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT
* [http://dissipatedheat.com/2011/11/10/how-not-to-write-a-patch-for-postgresql/ How not to write this patch.]
}}

{{TodoItem
|Improve type determination of unknown (NULL or quoted literal) result columns for UNION/INTERSECT/EXCEPT
* [http://archives.postgresql.org/message-id/9799.1302719551@sss.pgh.pa.us <nowiki>UNION construct type cast gives poor error message</nowiki>]
}}

{{TodoItem
|Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00838.php <nowiki>WIP: grouping sets support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00466.php <nowiki>Implementation of GROUPING SETS (T431: Extended grouping capabilities)</nowiki>]
}}

{{TodoItem
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables</nowiki>]
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]
}}

{{TodoItem
|Add a GUC variable to warn about non-standard SQL usage in queries}}

{{TodoItem
|Add SQL-standard MERGE/REPLACE/UPSERT command
|MERGE is typically used to merge two tables. REPLACE or UPSERT command does UPDATE, or on failure, INSERT. See [[SQL MERGE]] for notes on the implementation details.
}}

{{TodoItem
|Add NOVICE output level for helpful messages
|For example, have it warn about unjoined tables. This could also control automatic sequence/index creation messages.
}}

{{TodoItem
|Allow NOTIFY in rules involving conditionals}}

{{TodoItem
|Allow EXPLAIN to identify tables that were skipped because of constraint_exclusion
}}

{{TodoItem
|Simplify dropping roles that have objects in several databases}}

{{TodoItem
|Allow the count returned by SELECT, etc to be represented as an int64 to allow a higher range of values}}

{{TodoItem
|Add support for WITH RECURSIVE ... CYCLE
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php <nowiki>WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows</nowiki>]}}

{{TodoItem
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}

{{TodoItem
|Allow DISTINCT to work in multiple-argument aggregate calls}}

{{TodoItem
|Add comments on system tables/columns using the information in catalogs.sgml
|Ideally the information would be pulled from the SGML file automatically.}}

{{TodoItem
|Prevent the specification of conflicting transaction read/write options
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php <nowiki>Re: SET TRANSACTION and SQL Standard</nowiki>]
}}

{{TodoItem
|Support LATERAL subqueries
|Lateral subqueries can reference columns of tables defined outside the subquery at the same level, i.e. ''laterally''.
For example, a LATERAL subquery in a FROM clause could reference tables defined in the same FROM clause.
Currently only the columns of tables defined ''above'' subqueries are recognized.
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php <nowiki>LATERAL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php <nowiki>Re: LATERAL</nowiki>]
}}

{{TodoItem
|Prevent temporary tables created with ON COMMIT DELETE ROWS from repeatedly truncating the table on every commit if the table is already empty
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00842.php
* http://archives.postgresql.org/pgsql-performance/2010-03/msg00392.php
* http://archives.postgresql.org/pgsql-performance/2010-04/msg00046.php
}}

{{TodoItem
|Allow DELETE and UPDATE to be used with LIMIT and ORDER BY
* http://archives.postgresql.org/pgadmin-hackers/2010-04/msg00078.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01997.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00021.php
}}

{{TodoItemDone
|Improve caching of prepared query plans
}}

{{TodoItem
|Allow PREPARE of cursors}}

{{TodoItem
|Have DISCARD PLANS discard plans cached by functions
|DISCARD all should do the same.
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00431.php
}}

{{TodoItem
|Avoid multiple-evaluation of BETWEEN and IN arguments containing volatile expressions
* http://archives.postgresql.org/message-id/4D95B605.2020709@enterprisedb.com
}}

{{TodoItem
|Fix nested CASE-WHEN constructs
* http://archives.postgresql.org/message-id/4DDCEEB8.50602@enterprisedb.com
}}

=== CREATE ===
{{TodoSubsection}}

{{TodoItem
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}

{{TodoItem
|Have WITH CONSTRAINTS also create constraint indexes
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]
}}

{{TodoItem
|Move NOT NULL constraint information to pg_constraint
|Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. Another issue is that we should probably force NOT NULL to be propagated from parent tables to children, just as CHECK constraints are. (But then does dropping PRIMARY KEY affect children?)
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg01223.php
}}

{{TodoItem
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]
}}

{{TodoItem
|Add CREATE SCHEMA ... LIKE that copies a schema}}

{{TodoItem
|Fix CREATE OR REPLACE FUNCTION to not leave objects depending on the function in inconsistent state
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]
}}

{{TodoItem
|Allow temporary tables to exist as empty by default in all sessions
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php <nowiki>idea: global temp tables</nowiki>]
* [http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php <nowiki>Re: idea: global temp tables</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg01098.php <nowiki>global temporary tables</nowiki>]
}}

{{TodoItem
|Allow the creation of "distinct" types
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php <nowiki>Distinct types</nowiki>]
}}

{{TodoItem
|Consider analyzing temporary tables when they are first used in a query
|Autovacuum cannot analyze or vacuum temporary tables.
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php <nowiki>autovacuum and temp tables support</nowiki>]
}}

{{TodoItem
|Allow an unlogged table to be changed to logged
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00437.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00323.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00237.php
}}

{{TodoEndSubsection}}

=== UPDATE ===
{{TodoSubsection}}

{{TodoItem
|<nowiki>Allow UPDATE tab SET ROW (col, ...) = (SELECT...)</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg01308.php <nowiki>Re: [PATCHES] extension for sql update</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00865.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php <nowiki>Re: UPDATE using sub selects</nowiki>]
}}

{{TodoItem
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00016.php <nowiki>Re: Do we need a TODO? (was Re: Concurrently updating anupdatable view)</nowiki>]
}}

{{TodoItem
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows
|This is related to the previous item, which questions whether it even has the right semantics
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]
}}

{{TodoEndSubsection}}

=== ALTER ===
{{TodoSubsection}}

{{TodoItem
|Have ALTER TABLE RENAME of a SERIAL column rename the sequence
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItem
|Have ALTER SEQUENCE RENAME rename the sequence name stored in the sequence table
* [http://archives.postgresql.org/pgsql-bugs/2007-09/msg00092.php <nowiki>BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00007.php <nowiki>Re: BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItemEasy
|Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME or ALTER TABLE RENAME CONSTRAINT
* [http://archives.postgresql.org/pgsql-patches/2006-02/msg00168.php <nowiki>ALTER CONSTRAINT RENAME patch reverted</nowiki>]
}}

{{TodoItem
|Add ALTER DOMAIN to modify the underlying data type}}

{{TodoItem
|Allow ALTER TABLESPACE to move the tablespace to different directories}}

{{TodoItem
|Allow moving system tables to other tablespaces, where possible
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}

{{TodoItem
|Have ALTER INDEX update the name of a constraint using that index}}

{{TodoItem
|Allow column display reordering by recording a display, storage, and permanent id for every column?
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php <nowiki>Column reordering in pg_dump</nowiki>]
}}

{{TodoItem
|Allow deactivating (and reactivating) indexes via ALTER TABLE
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01191.php
}}

{{TodoItem
|Add ALTER OPERATOR ... RENAME
|needs to consider effects of changing operator precedence
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]
}}

{{TodoItem
|Add ALTER TABLE ... RENAME RULE
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]
}}

{{TodoEndSubsection}}

=== CLUSTER ===
{{TodoSubsection}}

{{TodoItem
|Automatically maintain clustering on a table
|This might require some background daemon to maintain clustering during periods of low usage. It might also require tables to be only partially filled for easier reorganization. Another idea would be to create a merged heap/index data file so an index lookup would automatically access the heap data too. A third idea would be to store heap rows in hashed groups, perhaps using a user-supplied hash function.
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]
* http://community.enterprisedb.com/git/
* [http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php <nowiki>Re: maintain_cluster_order_v5.patch</nowiki>]
}}

{{TodoEndSubsection}}

=== COPY ===
{{TodoSubsection}}

{{TodoItem
|Allow COPY to report error lines and continue
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure.
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]
}}

{{TodoItem
|Allow COPY FROM to create index entries in bulk
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]
}}

{{TodoItem
|Allow COPY in CSV mode to control whether a quoted zero-length string is treated as NULL
|Currently this is always treated as a zero-length string, which generates an error when loading into an integer column
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php <nowiki>Re: [PATCHES] allow CSV quote in NULL</nowiki>]
}}

{{TodoItem
|Improve COPY performance
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01882.php
}}

{{TodoItem
|Allow COPY to report errors sooner
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]
}}

{{TodoItem
|Allow COPY to handle other number formats
|E.g. the German notation. Best would be something like WITH DECIMAL ','.
}}

{{TodoItem
|Allow a stalled COPY to exit if the backend is terminated
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00067.php <nowiki>Re: possible bug not in open items</nowiki>]
}}

{{TodoEndSubsection}}

=== GRANT/REVOKE ===
{{TodoSubsection}}

{{TodoItem
|Allow SERIAL sequences to inherit permissions from the base table?}}

{{TodoItem
|Allow dropping of a role that has connection rights
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php <nowiki>DROP ROLE dependency tracking ...</nowiki>]
}}
{{TodoEndSubsection}}

=== DECLARE CURSOR ===
{{TodoSubsection}}

{{TodoItem
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}

{{TodoItem
|Provide some guarantees about the behavior of cursors that invoke volatile functions
* [http://archives.postgresql.org/message-id/20997.1244563664@sss.pgh.pa.us Re: Cursor with hold emits the same row more than once across commits in 8.3.7]
}}

{{TodoEndSubsection}}

=== INSERT ===
{{TodoSubsection}}

{{TodoItem
|Allow INSERT/UPDATE of the system-generated oid value for a row}}

{{TodoItem
|In rules, allow VALUES() to contain a mixture of 'old' and 'new' references}}

{{TodoEndSubsection}}

=== SHOW/SET ===
{{TodoSubsection}}

{{TodoItem
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}

{{TodoItem
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count
* [http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php <nowiki>Re: [ADMIN] shared_buffers and shmmax</nowiki>]
}}

{{TodoEndSubsection}}

=== ANALYZE ===
{{TodoSubsection}}

{{TodoItem
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}

{{TodoItem
|Have EXPLAIN ANALYZE report rows as floating-point numbers
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg01363.php <nowiki>explain analyze rows=%.0f</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00108.php <nowiki>Re: explain analyze rows=%.0f</nowiki>]
}}

{{TodoItem
|Improve how ANALYZE computes in-doubt tuples
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]
}}

{{TodoEndSubsection}}

=== Window Functions ===
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.
{{TodoSubsection}}
{{TodoItem
|Support creation of user-defined window functions
|We have the ability to create new window functions written in C. Is it
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}

{{TodoItem
|Implement full support for window framing clauses
|In addition to done clauses described in the [http://developer.postgresql.org/pgdocs/postgres/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS latest doc], these clauses are not implemented yet.
* RANGE BETWEEN ... PRECEDING/FOLLOWING
* EXCLUDE
}}

{{TodoItem
|Investigate tuplestore performance issues
|The tuplestore_in_memory() thing is just a band-aid, we ought to try to solve it properly. tuplestore_advance seems like a weak spot as well.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php <nowiki>tuplestore potential performance problem</nowiki>]
}}

{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}

{{TodoItem
|Teach planner to evaluate multiple windows in the optimal order
|Currently windows are always evaluated in the query-specified order.
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64
}}

{{TodoItem
|Implement DISTINCT clause in window aggregates
|Some proprietary RDBMSs have implemented it already, so it helps with porting from those.}}

{{TodoEndSubsection}}

== Integrity Constraints ==
=== Keys ===

{{TodoSubsection}}

{{TodoItem
|Improve deferrable unique constraints for cases with many conflicts
|The current implementation fires a trigger for each potentially conflicting row. This might not scale well for an update that changes many key values at once.
}}

{{TodoEndSubsection}}

=== Referential Integrity ===
{{TodoSubsection}}

{{TodoItem
|Add MATCH PARTIAL referential integrity}}

{{TodoItem
|Change foreign key constraint for array -> element to mean element in array?
* [http://archives.postgresql.org/pgsql-hackers/2010-10/msg01814.php <nowiki>foreign keys for array/period contains relationships</nowiki>]
}}

{{TodoItem
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]
}}

{{TodoItem
|Optimize referential integrity checks
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php <nowiki>Can't ri_KeysEqual() consider two nulls as equal?</nowiki>]
}}

{{TodoEndSubsection}}

== Server-Side Languages ==

{{TodoItem
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}

{{TodoItem
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}

{{TodoItem
|Add more fine-grained specification of functions taking arbitrary data types
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php <nowiki>RfD: more powerful "any" types</nowiki>]
}}

{{TodoItem
|Implement stored procedures
|This might involve the control of transaction state and the return of multiple result sets
* [http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php <nowiki>PL/pgSQL stored procedure returning multiple result sets (SELECTs)?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php
* [http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php <nowiki>Gathering specs and discussion on feature (post 9.1)</nowiki>]
}}

{{TodoItem
|Allow holdable cursors in SPI}}

{{TodoItemEasy
|Add SPI_gettypmod() to return a field's typemod from a TupleDesc
* http://archives.postgresql.org/pgsql-hackers/2005-11/msg00250.php
}}

=== SQL-Language Functions ===
{{TodoSubsection}}

{{TodoItem
|Allow SQL-language functions to reference parameters by parameter name
|Currently SQL-language functions can only refer to dollar parameters, e.g. $1
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01479.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01519.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00221.php
}}

{{TodoItem
|Rethink query plan caching and timing of parse analysis within SQL-language functions
|They should work more like plpgsql functions do ...
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00078.php <nowiki>Re: BUG #6019: invalid cached plan on inherited table</nowiki>]
}}

{{TodoEndSubsection}}

=== PL/pgSQL ===
{{TodoSubsection}}

{{TodoItem
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}

{{TodoItem
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki>
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
}}

{{TodoItem
|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.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]
}}

{{TodoItem
|Consider keeping separate cached copies when search_path changes
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]
}}

{{TodoItem
|Improve handling of NULL row values vs. NULL rows
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php <nowiki>Null row vs. row of nulls in plpgsql</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01973.php
}}

{{TodoItem
|Improve PERFORM handling of WITH queries or document limitation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00309.php
}}

{{TodoEndSubsection}}

=== PL/Perl ===
{{TodoSubsection}}

{{TodoItem
|Allow regex operations in plperl using UTF8 characters in non-UTF8 encoded databases}}

{{TodoEndSubsection}}

=== PL/Python ===
{{TodoSubsection}}

{{TodoItem
|Develop a trusted variant of PL/Python.}}

{{TodoItem
|Create a new restricted execution class that will allow passing function arguments in as locals. Passing them as globals means functions cannot be called recursively.
* [http://archives.postgresql.org/pgsql-hackers/2011-02/msg01468.php <nowiki>Re: pl/python do not delete function arguments</nowiki>]
}}

{{TodoItem
|Add a DB-API compliant interface on top of the SPI interface
* http://petereisentraut.blogspot.com/2011/11/plpydbapi-db-api-for-plpython.html
}}

{{TodoItem
|For functions returning a setof record with a composite type, cache the I/O functions for the composite type
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02007.php
}}

{{TodoItem
|Fix loss of information during conversion of numeric type to Python float}}

{{TodoEndSubsection}}

=== PL/Tcl ===
{{TodoSubsection}}

{{TodoItem
|Add table function support}}

{{TodoItem
|Check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, and SPI calls.}}

{{TodoEndSubsection}}

== Clients ==

{{TodoItem
|Add a function like pg_get_indexdef() that report more detailed index information
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00166.php <nowiki>BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)</nowiki>]
}}

{{TodoItem
|Split out pg_resetxlog output into pre- and post-sections
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php
}}

=== pg_ctl ===
{{TodoSubsection}}

{{TodoItemDone
|Allow pg_ctl to work properly with configuration files located outside the PGDATA directory
|pg_ctl can not read the pid file because it isn't located in the config directory but in the PGDATA directory. The solution is to allow pg_ctl to read and understand postgresql.conf to find the data_directory value.
* [http://archives.postgresql.org/pgsql-bugs/2009-10/msg00024.php <nowiki>BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory</nowiki>]
}}

{{TodoItem
|Modify pg_ctl behavior and exit codes to make it easier to write an LSB conforming init script
|It may be desirable to condition some of the changes on a command-line switch, to avoid breaking existing scripts. A Linux shell (sh) script is referenced which has been tested and seems to provide a high degree of conformance in multiple environments. Study of this script might suggest areas where pg_ctl could be modified to make writing an LSB conforming script easier; however, some aspects of that script would be unnecessary with other suggested changes to pg_ctl, and discussion on the lists did not reach consensus on support for all aspects of this script. Further discussion of particular changes is needed before beginning any work.
* [[Lsb_conforming_init_script|LSB conforming init script]]
These threads should be studied for other ideas on improvements:
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01390.php <nowiki>We should Axe /contrib/start-scripts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01843.php <nowiki>Linux LSB init script</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00008.php <nowiki>Re: Linux LSB init script</nowiki>]
}}

{{TodoItem
|Improve pg_ctl's detection of running postmasters
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00000.php
* http://archives.postgresql.org/pgsql-committers/2011-06/msg00001.php
}}

{{TodoEndSubsection}}

=== psql ===
{{TodoSubsection}}

{{TodoItem
|Have psql \ds show all sequences and their settings
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00916.php <nowiki>Re: TODO item: Have psql show current values for a sequence</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00401.php <nowiki>Quick patch: Display sequence owner</nowiki>]
}}

{{TodoItemDone
|Have \d on a sequence indicate if the sequence is owned by a table}}

{{TodoItem
|Move psql backslash database information into the backend, use mnemonic commands?
|This would allow non-psql clients to pull the same information out of the database as psql.
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]
}}

{{TodoItem
|Make psql's \d commands more consistent in their handling of schemas
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php <nowiki>Re: psql and schemas</nowiki>]
}}

{{TodoItem
|Make psql's \d commands distinguish default privileges from no privileges
|ACL displays were visibly different for the two cases before we "improved" them by using array_to_string.
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00082.php <nowiki>BUG #6021: There is no difference between default and empty access privileges with \dp</nowiki>]
}}

{{TodoItem
|Consistently display privilege information for all objects in psql}}

{{TodoItemDone
|Add "auto" expanded mode that outputs in expanded format if "wrapped" mode can't wrap the output to the screen width
|Consider using auto-expanded mode for backslash commands like \df+.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00417.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01638.php
}}

{{TodoItem
|Prevent tab completion of SET TRANSACTION from querying the database and therefore preventing the transaction isolation level from being set.
|Currently SET <tab> causes a database lookup to check all supported session variables. This query causes problems because setting the transaction isolation level must be the first statement of a transaction.}}

{{TodoItemEasy
|\s without arguments (display history) fails with libedit, doesn't use pager either
* [http://archives.postgresql.org/pgsql-bugs/2011-06/msg00114.php <nowiki> psql \s not working - OS X</nowiki>]
}}

{{TodoItem
|Add a \set variable to control whether \s displays line numbers
|Another option is to add \# which lists line numbers, and allows command execution.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]
}}

{{TodoItem
|Include the symbolic SQLSTATE name in verbose error reports
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]
}}

{{TodoItem
|Add prompt escape to display the client and server versions
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00310.php <nowiki>WIP patch for TODO Item: Add prompt escape to display the client and server versions</nowiki>]
}}

{{TodoItem
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.
|Currently, "wrapped" format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}

{{TodoItem
|Support the ReST table output format
|Details about the ReST format: http://docutils.sourceforge.net/rst.html#reference-documentation
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg01007.php <nowiki>Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00518.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00609.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
}}

{{TodoItem
|Add option to print advice for people familiar with other databases
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php <nowiki>MySQL-ism help patch for psql</nowiki>]
}}

{{TodoItemDone
|\dd is missing comments for several types of objects
|Comments are not handled at all for some object types, and are handled by both \dd and the individual backslash command for others. Consider a system view like pg_comments to manage this mess.
* [http://archives.postgresql.org/pgsql-general/2009-09/msg00199.php <nowiki>comment on constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php <nowiki>pg_comments</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2011-05/msg00885.php <nowiki>patch: Allow \dd to show constraint comments</nowiki>]
}}

{{TodoItem
|Add ability to edit views with \ev
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00023.php <nowiki>Adding \ev view editor?</nowiki>]
}}

{{TodoItem
|Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php
}}

{{TodoItem
|Prevent psql from sending remaining single-line multi-statement queries after reconnecting
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php
}}

{{TodoItemEasy
|Add \i option to bring in the specified file as a quoted literal
|This would be useful for creating functions and other areas. Details still need to be worked out.
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00016.php
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00020.php
}}

{{TodoItem
|Consider having psql -c read .psqlrc, for consistency
|psql -f already reads .psqlrc
}}

{{TodoItem
|Allow processing of multiple -f (file) options
}}

{{TodoItem
|Improve line drawing characters
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00386.php
}}

{{TodoItem
|Consider improving the continuation prompt
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01772.php
}}

{{TodoEndSubsection}}

=== pg_dump / pg_restore ===
{{TodoSubsection}}

{{TodoItemEasy
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}

{{TodoItem
|Add pg_dumpall custom format dumps?
* [http://archives.postgresql.org/pgsql-general/2010-05/msg00509.php pg_dumpall custom format]
|}}

{{TodoItem
|Avoid using platform-dependent locale names in pg_dumpall output
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us
}}

{{TodoItem
|Allow selection of individual object(s) of all types, not just tables}}

{{TodoItem
|In a selective dump, allow dumping of an object and all its dependencies}}

{{TodoItem
|Add options like pg_restore -l and -L to pg_dump}}

{{TodoItem
|Add support for multiple pg_restore -t options, like pg_dump
|pg_restore's -t switch is less useful than pg_dump's in quite a few ways: no multiple switches, no pattern matching, no ability to pick up indexes and other dependent items for a selected table. It should be made to handle this switch just like pg_dump does.}}

{{TodoItem
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}

{{TodoItem
|Allow pg_dump --clean to drop roles that own objects or have privileges
|tgl says: if this is about pg_dumpall, it's done as of 8.4. If it's really about pg_dump, what does it mean? pg_dump has no business dropping roles.}}

{{TodoItem
|Allow pg_dump to utilize multiple CPUs and I/O channels by dumping multiple objects simultaneously
|The difficulty with this is getting multiple dump processes to produce a single dump output file. It also would require several sessions to share the same snapshot.
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00040.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02454.php
}}

{{TodoItem
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}

{{TodoItem
|Remove support for dumping from pre-7.3 servers
|In 7.3 and later, we can get accurate dependency information from the server. pg_dump still contains a lot of crufty code
to try to deal with the lack of dependency info in older servers, but the usefulness of maintaining that code grows small.}}

{{TodoItemDone
|Allow pre/data/post files when schema and data are dumped separately, for performance reasons
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00185.php <nowiki>Re: pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00821.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
}}

{{TodoItem
|Refactor handling of database attributes between pg_dump and pg_dumpall
|Currently only pg_dumpall emits database attributes, such as ALTER DATABASE SET commands and database-level GRANTs.
Many people wish that pg_dump would do that. One proposal is to let pg_dump issue such commands if the -C switch was used,
but it's unclear whether that will satisfy the demand.
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2010-05/msg00010.php summary of the issues]
}}

{{TodoItem
|Change pg_dump so that a comment on the dumped database is applied to the loaded database, even if the database has a different name.
|This will require new backend syntax, perhaps COMMENT ON CURRENT DATABASE. This is related to the previous item.}}

{{TodoItem
|Allow parallel restore of tar dumps
* [http://archives.postgresql.org/pgsql-hackers/2009-02/msg01154.php <nowiki>Re: parallel restore</nowiki>]
}}

{{TodoItemDone
|Allow pg_dumpall to output restorable ALTER USER/DATABASE SET settings
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00916.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00394.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02359.php
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg00489.php
}}

{{TodoEndSubsection}}

=== ecpg ===
{{TodoSubsection}}

{{TodoItem
|Docs
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}

{{TodoItem
|Solve cardinality > 1 for input descriptors / variables?}}

{{TodoItem
|Add a semantic check level, e.g. check if a table really exists}}

{{TodoItem
|fix handling of DB attributes that are arrays}}

{{TodoItem
|Fix nested C comments}}

{{TodoItemEasy
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}

{{TodoItem
|Make SET CONNECTION thread-aware, non-standard?}}

{{TodoItem
|Allow multidimensional arrays}}

{{TodoItem
|Implement COPY FROM STDIN}}

{{TodoItem
|Provide a way to specify size of a bytea parameter
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]
}}

{{TodoItemEasy
|Fix small memory leaks in ecpg
|Memory leaks in a short running application like ecpg are not really a problem, but make debugging more complicated}}

{{TodoItem
|Allow reuse of cursor name variables
* [http://archives.postgresql.org/message-id/20100329113435.GA3430@feivel.credativ.lan <nowiki>Problems with variable cursorname in ecpg</nowiki>]
}}

{{TodoEndSubsection}}

=== libpq ===
{{TodoSubsection}}

{{TodoItem
|Prevent PQfnumber() from lowercasing unquoted column names
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}

{{TodoItem
|Allow statement results to be automatically batched to the client
|Currently all statement results are transferred to the libpq client before libpq makes the results available to the application. This feature would allow the application to make use of the first result rows while the rest are transferred, or held on the server waiting for them to be requested by libpq. One complexity is that a statement like SELECT 1/col could error out mid-way through the result set.}}

{{TodoItem
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]
}}

{{TodoItem
|Add PQexecf() that allows complex parameter substitution
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]
}}

{{TodoItem
|Add SQLSTATE and severity to errors generated within libpq itself
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01425.php
}}

{{TodoItem
|Add support for interface/ipaddress binding to libpq
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php <nowiki>SR/libpq - outbound interface/ipaddress binding</nowiki>]
}}

{{TodoEndSubsection}}

== Triggers ==

{{TodoItem
|Improve storage of deferred trigger queue
|Right now all deferred trigger information is stored in backend memory. This could exhaust memory for very large trigger queues. This item involves dumping large queues into files, or doing some kind of join to process all the triggers, some bulk operation, or a bitmap.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php <nowiki>Scaling up deferred unique checks and the after trigger queue</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00023.php
}}

{{TodoItem
|Allow triggers to be disabled in only the current session.
|This is currently possible by starting a multi-statement transaction, modifying the system tables, performing the desired SQL, restoring the system tables, and committing the transaction. ALTER TABLE ... TRIGGER requires a table lock so it is not ideal for this usage.}}

{{TodoItem
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}

{{TodoItem
|Allow statement-level triggers to access modified rows}}

{{TodoItem
|When statement-level triggers are defined on a parent table, have them fire only on the parent table, and fire child table triggers only where appropriate
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php <nowiki>Statement-level triggers and inheritance</nowiki>]
}}

{{TodoItem
|Allow AFTER triggers on system tables
|System tables are modified in many places in the backend without going through the executor and therefore not causing triggers to fire. To complete this item, the functions that modify system tables will have to fire triggers.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01665.php
* http://wiki.postgresql.org/wiki/DDL_Triggers
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg00022.php
}}

{{TodoItem
|Tighten trigger permission checks
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]
}}

{{TodoItem
|Allow BEFORE INSERT triggers on views
* [http://archives.postgresql.org/pgsql-general/2007-02/msg01466.php <nowiki>Re: Why can't I put a BEFORE EACH ROW trigger on a view?</nowiki>]
}}

{{TodoItem
|Add database and transaction-level triggers
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]
}}

{{TodoItem
|Reduce locking requirements for creating a trigger
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php <nowiki>Re: Change lock requirements for adding a trigger</nowiki>]
}}

{{TodoItem
|Avoid requirement for "AFTER" trigger functions to return a value
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02384.php
}}

== Inheritance ==

{{TodoItem
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys
* [http://archives.postgresql.org/pgsql-hackers/2010-05/msg00285.php <nowiki>Partitioning/inherited tables vs FKs</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00039.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00305.php
}}

{{TodoItem
|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.}}

{{TodoItem
|Determine whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY). If yes, implement it.}}

{{TodoItem
|ALTER TABLE variants sometimes support recursion and sometimes not, but this is poorly/not documented, and the ONLY marker would then be silently ignored. Clarify the documentation, and reject ONLY if it is not supported.}}

== Indexes ==

{{TodoItem
|Prevent index uniqueness checks when UPDATE does not modify the column
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.
However, HOT already short-circuits this in common cases, so more work might not be helpful.}}

{{TodoItem
|Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes
|Such indexes could be more compact if there are only a few distinct values. Such indexes can also be compressed. Keeping such indexes updated can be costly.
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php <nowiki>Bitmap Indexes: request for feedback</nowiki>]
* http://archives.postgresql.org/message-id/800923.27831.qm@web29010.mail.ird.yahoo.com
}}

{{TodoItem
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02179.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00459.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02054.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01731.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00894.php
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00679.php
}}

{{TodoItem
|Consider having a larger statistics target for indexed columns and expression indexes.
}}

{{TodoItem
|Consider smaller indexes that record a range of values per heap page, rather than having one index entry for every heap row
|This is useful if the heap is clustered by the indexed values.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00341.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01264.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00465.php <nowiki>Grouped Index Tuples / Clustered Indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php <nowiki>Bitmapscan changes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php <nowiki>Re: GIT patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php <nowiki>Re: Index Tuple Compression Approach?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php <nowiki>Re: Index AM change proposals, redux</nowiki>]
}}

{{TodoItem
|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.
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]
}}

{{TodoItem
|Allow multiple indexes to be created concurrently, ideally via a single heap scan
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00093.php
}}

{{TodoItem
|Consider sorting entries before inserting into btree index
* [http://archives.postgresql.org/pgsql-general/2008-01/msg01010.php <nowiki>Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?</nowiki>]
}}

{{TodoItem
|Allow index scans to return matching index keys, not just the matching heap locations
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01657.php <nowiki>Re: Is this TODO item done?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01477.php <nowiki>Index-only quals</nowiki>]
}}

{{TodoItem
|Allow creation of an index that can do comparisons to test if a value is between two column values
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00757.php <nowiki>Proposal: temporal extension "period" data type</nowiki>]
}}

{{TodoItem
|Consider using "effective_io_concurrency" for index scans
* Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.
}}

{{TodoItem
|Fix problem with btree page splits during checkpoints
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00052.php
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00184.php
}}

=== GIST ===
{{TodoSubsection}}

{{TodoItem
|Add more GIST index support for geometric data types}}

{{TodoItem
|Allow GIST indexes to create certain complex index types, like digital trees (see Aoki)}}

{{TodoItem
|Fix performance issues in contrib/seg and contrib/cube GiST support
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00069.php <nowiki>Re: GiST index performance</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2009-06/msg00068.php <nowiki>GiST index performance</nowiki>]
}}

{{TodoEndSubsection}}

=== Hash ===
{{TodoSubsection}}

{{TodoItem
|Add UNIQUE capability to hash indexes}}

{{TodoItem
|Add hash WAL logging for crash recovery
* http://archives.postgresql.org/pgsql-performance/2011-09/msg00196.php
}}

{{TodoItem
|Allow multi-column hash indexes}}

{{TodoEndSubsection}}

== Sorting ==

{{TodoItem
|Consider whether duplicate keys should be sorted by block/offset
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]
}}

{{TodoItem
|Consider being smarter about memory and external files used during sorts
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php <nowiki>Re: Sorting Improvements for 8.4</nowiki>]
}}

{{TodoItem
|Consider detoasting keys before sorting}}

{{TodoItem
|Allow sorts to use more available memory
* http://archives.postgresql.org/pgsql-hackers/2007-11/msg01026.php
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01123.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg01957.php
}}

== Fsync ==

{{TodoItem
|Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether fsync does anything
|Ideally this requires a separate test program like /contrib/pg_test_fsync that can be run at initdb time or optionally later.}}

{{TodoItem
|Consider sorting writes during checkpoint
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php <nowiki>Re: Sorting writes during checkpoint</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg02012.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00278.php
}}

== Cache Usage ==

{{TodoItemDone
|Speed up COUNT(*)
|We could use a fixed row count and a +/- count to follow MVCC visibility rules, or a single cached value could be used and invalidated if anyone modifies the table. Another idea is to get a count directly from a unique index, but for this to be faster than a sequential scan it must avoid access to the heap to obtain tuple visibility information. Note that the index-only scans feature is now implemented which now dramatically speeds up some COUNT(*) cases.
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItem
|Provide a way to calculate an "estimated COUNT(*)"
|Perhaps by using the optimizer's cardinality estimates or random sampling.
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php <nowiki>Re: Improving count(*)</nowiki>]
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItemDone
|Allow data to be pulled directly from indexes
|Currently indexes do not have enough tuple visibility information to allow data to be pulled from the index without also accessing the heap. The idea is to use the visibility map used for vacuum to avoid heap lookups on pages where all tuples are visible.
* [http://wiki.postgresql.org/wiki/Index-only_scans Index-Only Scans wiki]
}}

{{TodoItem
|Consider automatic caching of statements at various levels:
* Parsed query tree
* Query execute plan
* Query results

:
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]
}}

{{TodoItem
|Consider increasing internal areas (NUM_CLOG_BUFFERS) when shared buffers is increased
* [http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php <nowiki>Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php <nowiki>clog_buffers to 64 in 8.3?</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php <nowiki>CLOG Patch</nowiki>]
}}

{{TodoItem
|Consider decreasing the amount of memory used by PrivateRefCount
|
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php <nowiki>PrivateRefCount (for 8.3)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php <nowiki>Re: PrivateRefCount (for 8.3)</nowiki>]
}}

{{TodoItem
|Consider allowing higher priority queries to have referenced buffer cache pages stay in memory longer
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]
}}

== Vacuum ==

{{TodoItem
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]
}}

{{TodoItem
|Allow concurrent inserts to use recently created pages rather than creating new ones
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php
}}

{{TodoItem
|Consider having single-page pruning update the visibility map
* <nowiki>https://commitfest.postgresql.org/action/patch_view?id=75</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php <nowiki>Re: visibility maps and heap_prune</nowiki>]
}}

{{TodoItem
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]
}}

{{TodoItem
|Bias FSM towards returning free space near the beginning of the heap file, in hopes that empty pages at the end can be truncated by VACUUM
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php <nowiki>FSM search modes</nowiki>]
}}

{{TodoItem
|Consider a more compact data representation for dead tuple locations within VACUUM
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php <nowiki>Re: Have vacuum emit a warning when it runs out of maintenance_work_mem</nowiki>]
}}

{{TodoItem
|Provide more information in order to improve user-side estimates of dead space bloat in relations
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]
}}

{{TodoItem
|Improve locking behaviour of vacuum during trailing page truncation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00319.php
* http://archives.postgresql.org/message-id/4D8DF88E.7080205@Yahoo.com
}}

{{TodoItem
|Reduce the number of table scans performed by vacuum
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00605.php
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php
}}

=== Auto-vacuum ===
{{TodoSubsection}}

{{TodoItemEasy
|Issue log message to suggest VACUUM FULL if a table is nearly empty?}}

{{TodoItem
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can do that.
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]
}}

{{TodoItem
|Prevent autovacuum from running if an old transaction is still running from the last vacuum
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]
}}

{{TodoItem
|Have autoanalyze of parent tables occur when child tables are modified
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php
* http://archives.postgresql.org/pgsql-performance/2010-10/msg00271.php
}}

{{TodoEndSubsection}}

== Locking ==

{{TodoItem
|Fix priority ordering of read and write light-weight locks
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php <nowiki>lwlocks and starvation</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php <nowiki>Re: lwlocks and starvation</nowiki>]
}}

{{TodoItem
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]
}}

{{TodoItem
|Allow UPDATEs on only non-referential integrity columns not to conflict with referential integrity locks
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php <nowiki>Referential Integrity and SHARE locks</nowiki>]
}}

{{TodoItem
|Add idle_in_transaction_timeout GUC so locks are not held for long periods of time}}

{{TodoItem
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]
}}

{{TodoItem
|Detect deadlocks involving LockBufferForCleanup()
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
}}

{{TodoItem
|Allow finer control over who is cancelled in a deadlock
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01727.php
}}

{{TodoItem
|Consider a lock timeout parameter
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00485.php <nowiki>SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5</nowiki>]
}}

{{TodoItem
|Reduce number of unnecessary false positives in Serializable Snapshot Isolation
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00609.php <nowiki>SSI heap_insert and page-level predicate locks</nowiki>]
}}

== Startup Time Improvements ==

{{TodoItem
|Experiment with multi-threaded backend for backend creation
|This would prevent the overhead associated with process creation. Most operating systems have trivial process creation time compared to database startup overhead, but a few operating systems (Win32, Solaris) might benefit from threading. Also explore the idea of a single session using multiple threads to execute a statement faster.}}

{{TodoItem
|Allow backends to change their database without restart
|This allows for faster server startup.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00843.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00336.php
}}

== Write-Ahead Log ==

{{TodoItem
|Eliminate need to write full pages to WAL before page modification
|Currently, to protect against partial disk page writes, we write full page images to WAL before they are modified so we can correct any partial page writes during recovery. These pages can also be eliminated from point-in-time archive files.
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01191.php
}}

{{TodoItem
|When full page writes are off, write CRC to WAL and check file system blocks on recovery
|If CRC check fails during recovery, remember the page in case a later CRC for that page properly matches.}}

{{TodoItem
|Write full pages during file system write and not when the page is modified in the buffer cache
|This allows most full page writes to happen in the background writer. It might cause problems for applying WAL on recovery into a partially-written page, but later the full page will be replaced from WAL.}}

{{TodoItem
|Reduce WAL traffic so only modified values are written rather than entire rows
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php <nowiki>Reduction in WAL for UPDATEs</nowiki>]
}}

{{TodoItem
|Allow WAL information to recover corrupted pg_controldata
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]
}}

{{TodoItem
|Find a way to reduce rotational delay when repeatedly writing last WAL page
|Currently fsync of WAL requires the disk platter to perform a full rotation to fsync again. One idea is to write the WAL to different offsets that might reduce the rotational delay.
* [http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php <nowiki>500 tpsQL + WAL log implementation</nowiki>]
}}

{{TodoItem
|Speed WAL recovery by allowing more than one page to be prefetched
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay.
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]
}}

{{TodoItem
|Improve WAL concurrency by increasing lock granularity
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]
}}

{{TodoItem
|Be more aggressive about creating WAL files
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php <nowiki>Re: PANIC caused by open_sync on Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-07/msg01075.php <nowiki>PreallocXlogFiles</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2005-04/msg00556.php <nowiki>WAL/PITR additional items</nowiki>]
}}

{{TodoItem
|Have resource managers report the duration of their status changes
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]
}}

{{TodoItem
|Move pgfoundry's xlogdump to /contrib and have it rely more closely on the WAL backend code
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php <nowiki>xlogdump</nowiki>]
}}

{{TodoItem
|Close deleted WAL files held open in *nix by long-lived read-only backends
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]
}}

== Optimizer / Executor ==

{{TodoItem
|Improve selectivity functions for geometric operators}}

{{TodoItem
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]
}}

{{TodoItem
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG}}

{{TodoItem
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}

{{TodoItem
|Consider compressed annealing to search for query plans
|This might replace GEQO.
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us
}}

{{TodoItem
|Improve use of expression indexes for ORDER BY
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php <nowiki>Resjunk sort columns, Heikki's index-only quals patch, and bug #5000</nowiki>]
}}

{{TodoItem
|Modify the planner to better estimate caching effects
* http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php
}}

{{TodoItem
|Allow shared buffer cache contents to affect index cost computations
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php
}}

=== Hashing ===
{{TodoSubsection}}

{{TodoItem
|Consider using a hash for joining to a large IN (VALUES ...) list
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]
}}

{{TodoItem
|Allow single batch hash joins to preserve outer pathkeys
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|"lazy" hash tables - look up only the tuples that are actually requested
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid building the same hash table more than once during the same query
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid hashing for distinct and then re-hashing for hash join
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoEndSubsection}}

== Background Writer ==

{{TodoItem
|Consider having the background writer update the transaction status hint bits before writing out the page
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.}}

{{TodoItem
|Consider adding buffers the background writer finds reusable to the free list
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
}}

{{TodoItem
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
}}

{{TodoItem
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]
}}

{{TodoItem
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]
}}

== Concurrent Use of Resources ==

{{TodoItem
|Do async I/O for faster random read-ahead of data
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-09/msg00255.php <nowiki>Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-01/msg00170.php <nowiki>Bitmap index scan preread using posix_fadvise (Was: There's random access and then there's random access)</nowiki>]
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]
}}

{{TodoItem
|Experiment with multi-threaded backend for better I/O utilization
|This would allow a single query to make use of multiple I/O channels simultaneously. One idea is to create a background reader that can pre-fetch sequential and index scan pages needed by other backends. This could be expanded to allow concurrent reads from multiple devices in a partitioned table.
* http://archives.postgresql.org/pgsql-performance/2011-02/msg00123.php
}}

{{TodoItem
|Experiment with multi-threaded backend for better CPU utilization
|This would allow several CPUs to be used for a single query, such as for sorting or query execution.
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00945.php <nowiki>Multi CPU Queries - Feedback and/or suggestions wanted!</nowiki>]
}}

{{TodoItem
|SMP scalability improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

== TOAST ==

{{TodoItem
|Allow user configuration of TOAST thresholds
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]
}}

{{TodoItem
|Reduce unnecessary cases of deTOASTing
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]
}}

{{TodoItem
|Reduce costs of repeat de-TOASTing of values
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]
}}

== Monitoring ==
{{TodoItem
|Expand pg_stat_activity for easier integration with monitoring tools
|* http://archives.postgresql.org/message-id/4DFA13A5.2060200@2ndQuadrant.com
}}

{{TodoItem
|Add column to pg_stat_activity that shows the progress of long-running commands like CREATE INDEX and VACUUM
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00203.php <nowiki>EXPLAIN progress info</nowiki>]
* The CLUSTER/VACUUM FULL implementation would also be useful to track this way
}}

{{TodoItem
|Have pg_stat_activity display query strings in the correct client encoding
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php <nowiki>pg_stats queries versus per-database encodings</nowiki>]
}}

{{TodoItemEasy
|Expose pg_controldata via an SQL interface
|Helpful for monitoring replicated databases
* http://archives.postgresql.org/message-id/4B901D73.8030003@agliodbs.com
* [http://archives.postgresql.org/message-id/4B959D7A.6010907@joeconway.com initial patch]
}}

== Miscellaneous Performance ==

{{TodoItem
|Use mmap() rather than SYSV for shared buffers?
|This would remove the requirement for SYSV SHM but would introduce portability issues. Anonymous mmap (or mmap to /dev/zero) is required to prevent I/O overhead. We could also consider mmap() for writing WAL.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00750.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00756.php
}}

{{TodoItem
|Rather than consider mmap()-ing in 8k pages, consider mmap()'ing entire files into a backend?
|Doing I/O to large tables would consume a lot of address space or require frequent mapping/unmapping. Extending the file also causes mapping problems that might require mapping only individual pages, leading to thousands of mappings. Another problem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk before WAL is written.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01239.php
}}

{{TodoItem
|Consider ways of storing rows more compactly on disk:
* Reduce the row header size?
* Consider reducing on-disk varlena length from four bytes to two because a heap row cannot be more than 64k in length}}

{{TodoItem
|Consider transaction start/end performance improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php <nowiki>Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

{{TodoItem
|Allow configuration of backend priorities via the operating system
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]
}}

{{TodoItem
|Consider increasing the minimum allowed number of shared buffers
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]
}}

{{TodoItem
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]
}}

{{TodoItem
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]
}}

{{TodoItem
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]
}}

{{TodoItem
|Sort large UPDATE/DELETEs so it is done in heap order
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]
}}

{{TodoItemDone
|Allow one transaction to see tuples using the snapshot of another transaction
|This would assist multiple backends in working together.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php <nowiki>Transaction Snapshot Cloning</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00260.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00466.php
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00684.php
}}

{{TodoItem
|Consider decreasing the I/O caused by updating tuple hint bits
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php
}}

{{TodoItem
|Avoid the requirement of freezing pages that are infrequently modified
|If all rows on a page are visible, it is possible to set a bit in the visibility map (once the visibility map is 100% reliable) and not need to freeze the page, avoiding a page rewrite
* http://archives.postgresql.org/message-id/4BF701CF.2090205@agliodbs.com
* http://archives.postgresql.org/pgsql-hackers/2010-06/msg00082.php
}}

{{TodoItem
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]
}}

{{TodoItem
|Restructure truncation logic to be more resistant to failure
|This also involves not writing dirty buffers for a truncated or dropped relation
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php
}}

{{TodoItem
|Consider adding logic to increase large tables by more than 8k
|This would reduce file system fragmentation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00337.php
}}

== Miscellaneous Other ==

{{TodoItem
|Deal with encoding issues for filenames in the server filesystem
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}
}}

{{TodoItem
|Deal with encoding issues in the output of localeconv()
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]
}}

{{TodoItem
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg00846.php <nowiki>patch - Report the schema along table name in a referential failure error message</nowiki>]
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]
}}

{{TodoItemEasy
| Provide [http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html#LIBPQ-CONNECT-FALLBACK-APPLICATION-NAME fallback_application_name] in contrib/pgbench, oid2name, and dblink.
* {{MessageLink|w2g9837222c1004070216u3bc46b3ahbddfdffdbfb46212@mail.gmail.com|fallback_application_name and pgbench}}
}}

{{TodoItem
|Add 64-bit support to /contrib/pgbench
* http://archives.postgresql.org/pgsql-hackers/2010-07/msg00153.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00705.php
}}

== Source Code ==

{{TodoItem
|Add use of 'const' for variables in source tree
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00473.php
}}

{{TodoItemEasy
|Remove warnings created by -Wcast-align}}

{{TodoItem
|Move platform-specific ps status display info from ps_status.c to ports}}

{{TodoItem
|Add optional CRC checksum to heap and index pages
|One difficulty is how to prevent hint bit changes from affecting the computed CRC checksum.
* http://archives.postgresql.org/message-id/19934.1226601952%40sss.pgh.pa.us
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00002.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01028.php <nowiki>double-buffering page writes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00524.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01101.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00011.php <nowiki>Re: Block-level CRC checks</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00249.php
}}

{{TodoItem
|Consider a faster CRC32 algorithm
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php
}}

{{TodoItem
|Allow cross-compiling by generating the zic database on the target system}}

{{TodoItem
|Improve NLS maintenance of libpgport messages linked onto applications}}

{{TodoItem
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}

{{TodoItem
|Allow creation of universal binaries for Darwin
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]
}}

{{TodoItem
|Consider GnuTLS if OpenSSL license becomes a problem
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]
}}

{{TodoItem
|Consider making NAMEDATALEN more configurable in future releases}}

{{TodoItem
|Research use of signals and sleep wake ups
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]
}}

{{TodoItem
|Allow C++ code to more easily access backend code
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]
}}

{{TodoItem
|Consider simplifying how memory context resets handle child contexts
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]
}}

{{TodoItem
|Create three versions of libpgport to simplify client code
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]
}}

{{TodoItem
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]
}}

{{TodoItem
|Implement the non-threaded Avahi service discovery protocol
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]
}}

{{TodoItem
|Reduce data row alignment requirements on some 64-bit systems
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]
}}

{{TodoItem
|Restructure TOAST internal storage format for greater flexibility
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]
}}

{{TodoItem
| Add regression tests for pg_dump/restore
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01967.php <nowiki>"make install-check-pg_dump" target in src/regress]</nowiki>]
}}

{{TodoItem
| Research different memory allocation methods for lists
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php
}}

{{TodoItem
| Consider removing the attribute options cache
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00039.php
}}

{{TodoItem
| Restructure /contrib section
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00705.php
}}

=== /contrib/pg_upgrade ===
{{TodoSubsection}}

{{TodoItem
|Handle large object comments
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.
}}

{{TodoItem
|Consider using pg_depend for checking object usage in version.c
}}

{{TodoItem
|If reindex is necessary, allow it to be done in parallel with pg_dump custom format
}}

{{TodoItem
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary
|pg_class.oid is not preserved so schema.tablename must be used.
}}

{{TodoItem
|Improve testing, perhaps using the buildfarm
|The buildfarm has access to multiple versions of PostgreSQL.
}}

{{TodoItem
|Create machine-readable output of pg_controldata
|This would avoid parsing its output. The problem is we need pg_controldata output from both the old and new clusters so we would need to support both formats.
}}

{{TodoEndSubsection}}

=== Windows ===
{{TodoSubsection}}

{{TodoItem
|Remove configure.in check for link failure when cause is found}}

{{TodoItem
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}

{{TodoItem
|Allow psql to use readline once non-US code pages work with backslashes}}

{{TodoItem
|Fix problem with shared memory on the Win32 Terminal Server}}

{{TodoItem
|Improve signal handling
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]
}}

{{TodoItem
|Convert MSVC build system to remove most batch files
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]
}}

{{TodoItem
|Support pgxs when using MSVC}}

{{TodoItem
|Fix MSVC NLS support, like for to_char()
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php <nowiki>Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)</nowiki>]
}}

{{TodoItem
|Find a correct rint() substitute on Windows
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]
}}

{{TodoItem
|Fix global namespace issues when using multiple terminal server sessions
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}

{{TodoItem
|Change from the current autoconf/gmake build system to cmake
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01869.php <nowiki>About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)</nowiki>]
}}

{{TodoItem
|Improve consistency of path separator usage
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net
}}

{{TodoItem
|Fix cross-compiling on Windows
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php
}}

{{TodoItemDone
|Allow multiple Postgres clusters running on the same machine to distinguish themselves in the event log
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01297.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00574.php
}}

{{TodoEndSubsection}}

=== Wire Protocol Changes ===
{{TodoSubsection}}

{{TodoItem
|Allow dynamic character set handling}}

{{TodoItem
|Add decoded type, length, precision}}

{{TodoItem
|Mark result columns as known-not-null when possible
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]
}}

{{TodoItem
|Provide more control over planner treatment of statements being prepared}}

{{TodoItem
|Use compression?}}

{{TodoItem
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}

{{TodoItem
|Make sure upgrading to a 4.1 protocol version will actually work smoothly
* [http://archives.postgresql.org/message-id/28307.1318255008@sss.pgh.pa.us Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable]
}}

{{TodoEndSubsection}}

== Documentation ==

{{TodoItem
|Convert single quotes to apostrophes in the PDF documentation
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]
}}

{{TodoItem
|Provide a manpage for postgresql.conf
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Consider changing documentation format from SGML to XML
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]
* http://archives.postgresql.org/pgsql-docs/2011-04/msg00020.php
* http://wiki.postgresql.org/wiki/Switching_PostgreSQL_documentation_from_SGML_to_XML
}}

{{TodoItem
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com
}}

{{TodoItem
|Add diagrams to the documentation
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php
}}

== Exotic Features ==

{{TodoItem
|Add pre-parsing phase that converts non-ISO syntax to supported syntax
|This could allow SQL written for other databases to run without modification.}}

{{TodoItem
|Allow plug-in modules to emulate features from other databases}}

{{TodoItem
|Add features of Oracle-style packages
|A package would be a schema with session-local variables, public/private functions, and initialization functions. It is also possible to implement these capabilities in any schema and not use a separate "packages" syntax at all.
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]
}}

{{TodoItem
|Consider allowing control of upper/lower case folding of unquoted identifiers
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00849.php <nowiki>TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
}}

{{TodoItem
|Add autonomous transactions
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]
}}

{{TodoItem
|Give query progress indication
* [[Query progress indication]]
}}

{{TodoItem
|Rethink our type system
* [[Rethinking datatypes]]
}}

== Features We Do ''Not'' Want ==

The following features have been discussed ad nauseum on the PostgreSQL mailing lists and the consensus has been that the project is not interested in them. As such, if you are going to bring them up as potential features, you will want to be familiar with all of the arguments against these features which have been previously made over the years. If you decide to work on such features anyway, you should be aware that you face a higher-than-normal barrier to get the Project to accept them.

{{TodoItem
|All backends running as threads in a single process (not wanted)
|This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. Threading specific operations such as I/O, seq scans, and connection management has been discussed and will probably be implemented to enable specific performance features. Moving to a threaded engine would also require halting all other work on PostgreSQL for one to two years.}}

{{TodoItem
|"Oracle-style" optimizer hints (not wanted)
|Optimizer hints, as implemented in Oracle and other RDBMSes, are used to work around problems in the optimizer and introduce upgrade and maintenance issues. We would rather have such problems reported and fixed. We have discussed a more sophisticated system of per-class cost adjustment instead, but a specification remains to be developed. See [[OptimizerHintsDiscussion|Optimizer Hints Discussion]] for further information.}}

{{TodoItem
|Embedded server (not wanted)
|While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliably and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases. Besides, there are several very mature embedded SQL databases already available.}}

{{TodoItem
|Obfuscated function source code (not wanted)
|Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]
}}

{{TodoItem
|Indeterminate behavior for the GROUP BY clause (not wanted)
|At least one other database product allows specification of a subset of the result columns which GROUP BY would need to be able to provide predictable results; the server is free to return any value from the group. This is not viewed as a desirable feature. PostgreSQL 9.1 allows result columns that are not referenced by GROUP BY if a primary key for the same table is referenced in GROUP BY.
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]
}}

</div>

[[Category:Todo]]

Todo

2011-10-26T18:41:58Z

Petere: /* Wire Protocol Changes */ Make sure upgrading to a 4.1 protocol version will actually work smoothly

<div style="margin: 1ex 1em; float: right;">
__TOC__
</div>

This list contains '''all known PostgreSQL bugs and feature requests'''. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].

* {{TodoPending}} - marks ordinary, incomplete items
* {{TodoEasy}} - marks items that are easier to implement
* {{TodoDone}} - marks changes that are done, and will appear in the PostgreSQL 9.2 release.

For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the mailing list.</b>

<div style="padding: 1ex 4em;">
== Administration ==

{{TodoItem
|Allow administrators to cancel multi-statement idle transactions
|This allows locks to be released, but it is complex to report the cancellation back to the client.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php <nowiki>Cancelling idle in transaction state</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00441.php <nowiki>Re: Cancelling idle in transaction state</nowiki>]
}}

{{TodoItem
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]
}}

{{TodoItem
|Set proper permissions on non-system schemas during db creation
|Currently all schemas are owned by the super-user because they are copied from the template1 database. However, since all objects are inherited from the template database, it is not clear that setting schemas to the db owner is correct.}}

{{TodoItem
|Allow log_min_messages to be specified on a per-module basis
|This would allow administrators to see more detailed information from specific sections of the backend, e.g. checkpoints, autovacuum, etc. Another idea is to allow separate configuration files for each module, or allow arbitrary SET commands to be passed to them. See also [[Logging Brainstorm]].}}

{{TodoItem
|Simplify creation of partitioned tables
|This would allow creation of partitioned tables without requiring creation of triggers or rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. See also [[Table partitioning]]
}}

{{TodoItem
|Allow custom variables to appear in pg_settings()
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]
}}

{{TodoItem
|Have custom variables be transaction-safe
* {{MessageLink|4B577E9F.8000505@dunslane.net|Custom GUCs still a bit broken}}
}}

{{TodoItem
|Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]
}}

{{TodoItem
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]
}}

{{TodoItem
|Provide a way to query the log collector subprocess to determine the name of the currently active log file
* [http://archives.postgresql.org/pgsql-general/2008-11/msg00418.php <nowiki>Current log files when rotating?</nowiki>]
}}

{{TodoItem
|Allow simpler reporting of the unix domain socket directory and allow easier configuration of its default location
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01555.php
}}

{{TodoItem
|Allow custom daemons to be automatically stopped/started along with the postmaster
|This allows easier administration of daemons like user job schedulers or replication-related daemons.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01701.php <nowiki>Re: scheduler in core</nowiki>]
}}

{{TodoItem
|Improve logging of prepared transactions recovered during startup
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>"recovering prepared transaction" after server restart message</nowiki>]
}}

{{TodoItem
|Consider using POSIX shared memory to avoid System V shared memory kernel limits
* [http://archives.postgresql.org/message-id/4DFA2673.3010009@enterprisedb.com <nowiki>POSIX shared memory patch status</nowiki>]
}}

{{TodoItem
|Address problem where superusers are assumed to be members of all groups
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
}}

=== Configuration files ===
{{TodoSubsection}}

{{TodoItemEasy
|Change pg_ident.conf parsing to be the same as pg_hba.conf
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg02204.php
}}

{{TodoItem
|Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00764.php
}}

{{TodoItem
|Consider normalizing fractions in postgresql.conf, perhaps using '%'
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]
}}

{{TodoItem
|Allow Kerberos to disable stripping of realms so we can check the username@realm against multiple realms
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php <nowiki>krb_match_realm patch</nowiki>]
}}

{{TodoItem
|Improve LDAP authentication configuration options
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php <nowiki>Proposed Patch - LDAPS support for servers on port 636 w/o TLS</nowiki>]
}}

{{TodoItem
|Add external tool to auto-tune some postgresql.conf parameters
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php <nowiki>Simple postgresql.conf wizard</nowiki>]
}}

{{TodoItem
|Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php <nowiki>Re: Plans for 8.4</nowiki>]
}}

{{TodoItem
|Process pg_hba.conf keywords as case-insensitive
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00432.php <nowiki>More robust pg_hba.conf parsing/error logging</nowiki>]
}}

{{TodoItem
|Create utility to compute accurate random_page_cost value
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00162.php
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00362.php
}}

{{TodoItem
|Allow configuration files to be independently validated
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php
* http://archives.postgresql.org/message-id/12666.1310774573@sss.pgh.pa.us
}}

{{TodoItem
|Allow postgresql.conf settings to be accepted by backends even if some settings are invalid for those backends
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoItem
|Allow all backends to receive postgresql.conf setting changes at the same time
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoEndSubsection}}

=== Tablespaces ===
{{TodoSubsection}}

{{TodoItem
|Allow a database in tablespace t1 with tables created in tablespace t2 to be used as a template for a new database created with default tablespace t2
|Currently all objects in the default database tablespace must have default tablespace specifications. This is because new databases are created by copying directories. If you mix default tablespace tables and tablespace-specified tables in the same directory, creating a new database from such a mixed directory would create a new database with tables that had incorrect explicit tablespaces. To fix this would require modifying pg_class in the newly copied database, which we don't currently do.}}

{{TodoItem
|Allow reporting of which objects are in which tablespaces
|This item is difficult because a tablespace can contain objects from multiple databases. There is a server-side function that returns the databases which use a specific tablespace, so this requires a tool that will call that function and connect to each database to find the objects in each database for that tablespace.}}

{{TodoItem
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original}}

{{TodoItem
|Allow per-tablespace quotas}}

{{TodoItem
|Allow tablespaces on RAM-based partitions for unlogged tables
* http://archives.postgresql.org/pgsql-advocacy/2011-05/msg00033.php
}}

{{TodoItem
|Allow toast tables to be moved to a different tablespace
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00980.php
}}

{{TodoEndSubsection}}

=== Statistics Collector ===
{{TodoSubsection}}

{{TodoItem
|Allow statistics last vacuum/analyze execution times to be displayed without requiring track_counts to be enabled
* [http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php <nowiki>row-level stats and last analyze time</nowiki>]
}}

{{TodoItem
|Clear table counters on TRUNCATE
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php <nowiki>Small TRUNCATE glitch</nowiki>]
}}

{{TodoEndSubsection}}

=== SSL ===
{{TodoSubsection}}

{{TodoItem
|Allow SSL authentication/encryption over unix domain sockets
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00924.php <nowiki>Re: Spoofing as the postmaster</nowiki>]
}}

{{TodoItem
|Allow SSL key file permission checks to be optionally disabled when sharing SSL keys with other applications
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php <nowiki>BUG #3809: SSL "unsafe" private key permissions bug</nowiki>]
}}

{{TodoItem
|Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart
|Unlike SSL CRT files, CRL (Certificate Revocation List) files are updated frequently
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00832.php <nowiki>Automatic CRL reload</nowiki>]
Alternatively or additionally supporting OCSP (online certificate security protocol) would provide real-time revocation discovery without reloading
}}

{{TodoItem
| Allow automatic selection of SSL client certificates from a certificate store
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]
}}

{{TodoItem
| Send the full certificate server chain to the client
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]
}}

{{TodoEndSubsection}}

=== Point-In-Time Recovery (PITR) ===
{{TodoSubsection}}

{{TodoItemEasy
|Create dump tool for write-ahead logs for use in determining transaction id for point-in-time recovery
|This is useful for checking PITR recovery.}}

{{TodoItem
|Allow archive_mode to be changed without server restart?
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php <nowiki>Enabling archive_mode without restart</nowiki>]
}}

{{TodoItem
|Consider avoiding WAL switching via archive_timeout if there has been no database activity
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01469.php <nowiki>archive_timeout behavior for no activity</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg00395.php <nowiki>Re: archive_timeout behavior for no activity</nowiki>]
}}

{{TodoEndSubsection}}

=== Standby server mode ===
{{TodoSubsection}}

{{TodoItem
| Allow pg_xlogfile_name() to be used in recovery mode
* [http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12@mail.gmail.com <nowiki>Streaming replication and pg_xlogfile_name()</nowiki>]
}}

{{TodoItem
| Prevent variables inherited from the server environment from begin used for making streaming replication connections.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01011.php <nowiki>Re: Parameter name standby_mode</nowiki>]
}}

{{TodoItemDone
| Allow hot file system backups on standby servers
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01727.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
}}

{{TodoItem
| Change walsender so that it applies per-role settings
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00642.php
}}

{{TodoItem
| Add more control over waiting for synchronous commit
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01611.php
}}

{{TodoItem
| Restructure configuration parameters for standby mode
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01820.php
}}

{{TodoItem
| Allow time-delayed application of logs on the standby
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00992.php
}}
{{TodoItem
| Add -X parameter to pg_basebackup to specify a different directory for px_xlog, like initdb
}}

{{TodoEndSubsection}}

== Data Types ==

{{TodoItem
|Fix data types where equality comparison is not intuitive, e.g. box}}

{{TodoItem
|Add support for public SYNONYMs
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php
* http://archives.postgresql.org/pgsql-general/2010-12/msg00139.php
}}

{{TodoItem
|Add support for SQL-standard GENERATED/IDENTITY columns
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]
}}

{{TodoItem
|Consider placing all sequences in a single table, or create a system view
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItem
|Consider a special data type for regular expressions
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]
}}

{{TodoItem
|Reduce BIT data type overhead using short varlena headers
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php <nowiki>storage size of "bit" data type..</nowiki>]
}}

{{TodoItem
|Allow renaming and deleting enumerated values from an existing enumerated data type
}}

{{TodoItem
|Support scoped IPv6 addresses in the inet type
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php <nowiki>strange problem with ip6</nowiki>]
}}

{{TodoItem
|Add a JSON (JavaScript Object Notation) data type
|This would behave similar to the XML data type, which is stored as text, but allows element lookup and conversion functions.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01494.php <nowiki>PATCH: Add hstore_to_json()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg00001.php <nowiki>Re: PATCH: Add hstore_to_json()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg01092.php <nowiki>Proposal: Add JSON support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00057.php <nowiki>Re: Proposal: Add JSON support</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00481.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01694.php
}}

{{TodoItem
|Considering improving performance of computing CHAR() value lengths
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00900.php <nowiki>char() overhead on read-only workloads not so insignifcant as the docs claim it is...</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01787.php <nowiki>Re: [PATCH] backend: compare word-at-a-time in bcTruelen</nowiki>]
}}

{{TodoItem
|Add overlaps geometric operators that ignore point overlaps
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00861.php
}}

=== Domains ===
{{TodoSubsection}}

{{TodoItem
|Allow functions defined as casts to domains to be called during casting
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]
}}

{{TodoItem
|Allow values to be cast to domain types
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00812.php
}}

{{TodoItem
|Make domains work better with polymorphic functions
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]
}}

{{TodoEndSubsection}}

=== Dates and Times ===
{{TodoSubsection}}

{{TodoItem
|Allow infinite intervals just like infinite timestamps}}

{{TodoItem
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules.
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]
}}

{{TodoItem
|Have timestamp subtraction not call justify_hours()?
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]
}}

{{TodoItem
|Improve TIMESTAMP WITH TIME ZONE subtraction to be DST-aware
|Currently subtracting one date from another that crosses a daylight savings time adjustment can return '1 day 1 hour', but adding that back to the first date returns a time one hour in the future. This is caused by the adjustment of '25 hours' to '1 day 1 hour', and '1 day' is the same time the next day, even if daylight savings adjustments are involved.}}

{{TodoItem
|Fix interval display to support values exceeding 2^31 hours}}

{{TodoItem
|Add overflow checking to timestamp and interval arithmetic}}

{{TodoItem
|Add function to allow the creation of timestamps using parameters
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00232.php
}}

{{TodoEndSubsection}}

=== Arrays ===
{{TodoSubsection}}

{{TodoItem
|Add support for arrays of domains
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php <nowiki>Re: updated WIP: arrays of composites</nowiki>]
}}

{{TodoItem
|Allow single-byte header storage for array elements}}

{{TodoItem
|Add function to detect if an array is empty
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php <nowiki>Re: array_length()</nowiki>]
}}

{{TodoItem
|Improve handling of empty arrays
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php <nowiki>So what's an "empty" array anyway?</nowiki>]
}}

{{TodoItem
|Improve handling of NULLs in arrays
* [http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php <nowiki>BUG #4509: array_cat's null behaviour is inconsistent</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php
}}

{{TodoEndSubsection}}

=== Binary Data ===
{{TodoSubsection}}

{{TodoItem
|Improve vacuum of large objects, like contrib/vacuumlo?}}

{{TodoItem
|Auto-delete large objects when referencing row is deleted
|contrib/lo offers this functionality.}}

{{TodoItem
|Allow read/write into TOAST values like large objects
|Writing might require the TOAST column to be stored EXTERNAL.
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00049.php
}}

{{TodoItem
|Add API for 64-bit large object access
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00781.php <nowiki>64-bit API for large objects</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01790.php
}}

{{TodoEndSubsection}}

=== MONEY Data Type ===
{{TodoSubsection}}

{{TodoItem
|Add locale-aware MONEY type, and support multiple currencies
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]
}}

{{TodoItem
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}

{{TodoEndSubsection}}

=== Text Search ===
{{TodoSubsection}}

{{TodoItem
|Allow dictionaries to change the token that is passed on to later dictionaries
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]
}}

{{TodoItem
|Consider a function-based API for '@@' searches
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Simplifying Text Search</nowiki>]
}}

{{TodoItem
|Improve text search error messages
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php <nowiki>Re: Poorly designed tsearch NOTICEs</nowiki>]
}}

{{TodoItem
|Consider changing error to warning for strings larger than one megabyte
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00062.php <nowiki>Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
}}

{{TodoItem
|tsearch and tsdicts regression tests fail in Turkish locale on glibc
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]
}}

{{TodoItem
|tsquery negator operator treated as part of lexeme
* [http://archives.postgresql.org/pgsql-bugs/2009-06/msg00346.php BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation]
}}

{{TodoItem
|Improve handling of plus signs in email address user names, and perhaps improve URL parsing
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00772.php
}}

{{TodoItem
|Improve default parser, to more easily allow adding new tokens
* http://archives.postgresql.org/message-id/23485.1297727826@sss.pgh.pa.us
}}

{{TodoItem
|Add additional support functions
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00319.php
}}

{{TodoEndSubsection}}

=== XML ===
{{TodoSubsection}}

{{TodoItem
|Allow XML arrays to be cast to other data types
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
}}

{{TodoItem
|Add XML Schema validation and xmlvalidate functions (SQL:2008)}}

{{TodoItem
|Add xmlvalidatedtd variant to support validating against a DTD?}}

{{TodoItem
|Relax-NG validation; libxml2 supports this already}}

{{TodoItem
|Allow reliable XML operation non-UTF8 server encodings (xpath(), in particular, is known to not work)
* [http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php <nowiki>BUG #4622: xpath only work in utf-8 server encoding</nowiki>]
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}

{{TodoItem
|Add functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}

{{TodoItem
|Add XMLNAMESPACES support in XMLELEMENT and elsewhere}}

{{TodoItem
|Move XSLT from contrib/xml2 to a more reasonable location
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00539.php
}}

{{TodoItem
|Report errors returned by the XSLT library
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00562.php
}}

{{TodoItem
|Improve the XSLT parameter passing API
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00416.php
}}

{{TodoItem
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}

{{TodoItem
|Add pretty-printed XML output option
|Parse a document and serialize it back in some indented form. libxml2 might support this.}}

{{TodoItem
|Add XMLQUERY (from the SQL/XML standard)}}

{{TodoItem
|Allow XML sthredding
|In some cases shredding could be better option (if there is no need to keep XML docs entirely, e.g. if we have already developed tools that understand only relational data. This would be a separate module that implements annotated schema decomposition technique, similar to DB2 and SQL Server functionality.}}

{{TodoItem
|Fix Nested or repeated xpath() that apparently mess up namespaces [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00097.php] [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00144.php] [http://archives.postgresql.org/pgsql-general/2008-03/msg00295.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/message-id/004f01c90e91$138e9d10$3aabd730$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|XPath: Adding the <x> at the root causes problems [http://archives.postgresql.org/pgsql-bugs/2008-05/msg00184.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/pgsql-general/2008-07/msg00613.php]}}

{{TodoItem
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}

{{TodoItem
|xpath_table is pretty broken anyway [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php]}}

{{TodoItem
|better handling of XPath data types [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php] [http://archives.postgresql.org/message-id/004a01c90e90$4b986d90$e2c948b0$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|Improve handling of PIs and DTDs in xmlconcat() [http://archives.postgresql.org/message-id/200904211211.n3LCB09p008988@wwwmaster.postgresql.org]}}

{{TodoItem
|Restructure XML and /contrib/xml2 functionality
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02314.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00017.php
}}

{{TodoEndSubsection}}

== Functions ==

{{TodoItem
|Allow INET subnet comparisons using non-constants to be indexed}}

{{TodoItem
|Add an INET overlaps operator, for use by exclusion constraints
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00845.php
}}

{{TodoItem
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php <nowiki>RFC for adding typmods to functions</nowiki>]
}}

{{TodoItem
|Fix IS OF so it matches the ISO specification, and add documentation
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]
}}

{{TodoItem
|Implement Boyer-Moore searching in LIKE queries
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}
}}

{{TodoItem
|Prevent malicious functions from being executed with the permissions of unsuspecting users
|Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]
}}

{{TodoItem
|Reduce memory usage of aggregates in set returning functions
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]
}}

{{TodoItem
|Fix /contrib/ltree operator
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]
}}

{{TodoItem
|Fix /contrib/btree_gist's implementation of inet indexing
* [http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php <nowiki>BUG #5705: btree_gist: Index on inet changes query result</nowiki>]
}}

{{TodoItem
|<nowiki>Fix inconsistent precedence of =, >, and < compared to <>, >=, and <=</nowiki>
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php <nowiki>BUG #3822: Nonstandard precedence for comparison operators</nowiki>]
}}

{{TodoItem
|Fix regular expression bug when using complex back-references
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php <nowiki>BUG #3645: regular expression back references seem broken</nowiki>]
}}

{{TodoItem
|Have /contrib/dblink reuse unnamed connections
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php <nowiki>dblink un-named connection doesn't get re-used</nowiki>]
}}

{{TodoItem
|Improve formatting of pg_get_viewdef() output
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01648.php <nowiki>pg_get_viewdef formattiing</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01885.php <nowiki>Re: pretty print viewdefs</nowiki>]
}}

{{TodoItem
|Add function to dump pg_depend information cleanly
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00226.php <nowiki>Elementary dependency look-up</nowiki>]
}}

{{TodoItem
|Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation
* [http://archives.postgresql.org/message-id/28488.1286461610@sss.pgh.pa.us pg_relation_size / could not open relation with OID #]
}}

=== Character Formatting ===

{{TodoSubsection}}
{{TodoItem
|Allow to_date() and to_timestamp() to accept localized month names}}

{{TodoItem
|Add missing parameter handling in to_char()
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]
}}

{{TodoItem
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]
}}

{{TodoItem
|Allow to_char() on interval values to accumulate the highest unit requested
|2= Some special format flag would be required to request such accumulation. Such functionality could also be added to EXTRACT. Prevent accumulation that crosses the month/day boundary because of the uneven number of days in a month.
* to_char(INTERVAL '1 hour 5 minutes', 'MI') => 65
* to_char(INTERVAL '43 hours 20 minutes', 'MI' ) => 2600
* to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') => 0:1:19:20
* to_char(INTERVAL '3 years 5 months','MM') => 41
}}

{{TodoItem
|Fix to_number() handling for values not matching the format string
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php <nowiki>Re: numeric_to_number() function skipping some digits</nowiki>]
}}

{{TodoEndSubsection}}

== Multi-Language Support ==

{{TodoItem
|Add NCHAR (as distinguished from ordinary varchar),}}

{{TodoItem
|Add a cares-about-collation column to pg_proc, so that unresolved-collation errors can be thrown at parse time
* [http://archives.postgresql.org/pgsql-hackers/2011-03/msg01520.php <nowiki>Open issues for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with text search configurations
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with to_char() and related functions
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Support collation-sensitive equality and hashing functions
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00472.php <nowiki> contrib/citext versus collations</nowiki>]
}}

{{TodoItem
|Add a LOCALE option to CREATE DATABASE, as a shorthand
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]
}}

{{TodoItem
|Support multiple simultaneous character sets, per SQL:2008}}

{{TodoItem
|Improve UTF8 combined character handling?}}

{{TodoItem
|Add octet_length_server() and octet_length_client()}}

{{TodoItem
|Make octet_length_client() the same as octet_length()?}}

{{TodoItem
|Fix problems with wrong runtime encoding conversion for NLS message files}}

{{TodoItem
|Add URL to more complete multi-byte regression tests
* [http://archives.postgresql.org/pgsql-hackers/2005-07/msg00272.php <nowiki>Multi-byte and client side character encoding tests for copy command..</nowiki>]
}}

{{TodoItem
|Fix contrib/fuzzystrmatch to work with multibyte encodings
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00138.php <nowiki> dmetaphone woes</nowiki>]
}}

{{TodoItem
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions
|Currently we preallocate memory based on worst-case usage.}}

{{TodoItem
|Add ability to use case-insensitive regular expressions on multi-byte characters
|Currently it works for UTF-8, but not other multi-byte encodings
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php <nowiki>Regexps vs. locale</nowiki>]
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}
}}

{{TodoItem
|Improve encoding of connection startup messages sent to the client
|Currently some authentication error messages are sent in the server encoding
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php <nowiki>encoding of PostgreSQL messages</nowiki>]
* [http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php <nowiki>Re: encoding of PostgreSQL messages</nowiki>]
}}

{{TodoItem
|More sensible support for Unicode combining characters, normal forms
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net
}}

== Views / Rules ==

{{TodoItem
|Automatically create rules on views so they are updateable, per SQL:2008
|We can only auto-create rules for simple views. For more complex cases users will still have to write rules manually.
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php <nowiki>Proposal for updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-08/msg00255.php <nowiki>Updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php <nowiki>Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle</nowiki>]
* http://wiki.postgresql.org/wiki/Updatable_views
}}

{{TodoItem
|Add the functionality of the WITH CHECK OPTION clause to CREATE VIEW}}

{{TodoItem
|Allow VIEW/RULE recompilation when the underlying tables change
|This is both difficult and controversial.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
}}

{{TodoItem
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]
}}

{{TodoItem
|Add the ability to automatically create materialized views
|Right now materialized views require the user to create triggers on the main table to keep the summary table current. SQL syntax should be able to manage the triggers and summary table automatically. A more sophisticated implementation would automatically retrieve from the summary table when the main table is referenced, if possible. See [[Materialized Views]] for implementation details
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00479.php <nowiki>GSoC - proposal - Materialized Views in PostgreSQL</nowiki>]
}}

{{TodoItem
|Improve ability to modify views via ALTER TABLE
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]
}}

{{TodoItem
|Prevent low-cost functions from seeing unauthorized view rows
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg01346.php <nowiki>Using views for row-level access control is leaky</nowiki>]
}}

== SQL Commands ==

{{TodoItem
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT}}

{{TodoItem
|Improve type determination of unknown (NULL or quoted literal) result columns for UNION/INTERSECT/EXCEPT
* [http://archives.postgresql.org/message-id/9799.1302719551@sss.pgh.pa.us <nowiki>UNION construct type cast gives poor error message</nowiki>]
}}

{{TodoItem
|Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00838.php <nowiki>WIP: grouping sets support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00466.php <nowiki>Implementation of GROUPING SETS (T431: Extended grouping capabilities)</nowiki>]
}}

{{TodoItem
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables</nowiki>]
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]
}}

{{TodoItem
|Add a GUC variable to warn about non-standard SQL usage in queries}}

{{TodoItem
|Add SQL-standard MERGE/REPLACE/UPSERT command
|MERGE is typically used to merge two tables. REPLACE or UPSERT command does UPDATE, or on failure, INSERT. See [[SQL MERGE]] for notes on the implementation details.
}}

{{TodoItem
|Add NOVICE output level for helpful messages
|For example, have it warn about unjoined tables. This could also control automatic sequence/index creation messages.
}}

{{TodoItem
|Allow NOTIFY in rules involving conditionals}}

{{TodoItem
|Allow EXPLAIN to identify tables that were skipped because of constraint_exclusion
}}

{{TodoItem
|Simplify dropping roles that have objects in several databases}}

{{TodoItem
|Allow the count returned by SELECT, etc to be represented as an int64 to allow a higher range of values}}

{{TodoItem
|Add support for WITH RECURSIVE ... CYCLE
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php <nowiki>WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows</nowiki>]}}

{{TodoItem
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}

{{TodoItem
|Allow DISTINCT to work in multiple-argument aggregate calls}}

{{TodoItem
|Add comments on system tables/columns using the information in catalogs.sgml
|Ideally the information would be pulled from the SGML file automatically.}}

{{TodoItem
|Prevent the specification of conflicting transaction read/write options
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php <nowiki>Re: SET TRANSACTION and SQL Standard</nowiki>]
}}

{{TodoItem
|Support LATERAL subqueries
|Lateral subqueries can reference columns of tables defined outside the subquery at the same level, i.e. ''laterally''.
For example, a LATERAL subquery in a FROM clause could reference tables defined in the same FROM clause.
Currently only the columns of tables defined ''above'' subqueries are recognized.
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php <nowiki>LATERAL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php <nowiki>Re: LATERAL</nowiki>]
}}

{{TodoItem
|Prevent temporary tables created with ON COMMIT DELETE ROWS from repeatedly truncating the table on every commit if the table is already empty
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00842.php
* http://archives.postgresql.org/pgsql-performance/2010-03/msg00392.php
* http://archives.postgresql.org/pgsql-performance/2010-04/msg00046.php
}}

{{TodoItem
|Allow DELETE and UPDATE to be used with LIMIT and ORDER BY
* http://archives.postgresql.org/pgadmin-hackers/2010-04/msg00078.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01997.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00021.php
}}

{{TodoItemDone
|Improve caching of prepared query plans
}}

{{TodoItem
|Allow PREPARE of cursors}}

{{TodoItem
|Have DISCARD PLANS discard plans cached by functions
|DISCARD all should do the same.
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00431.php
}}

{{TodoItem
|Avoid multiple-evaluation of BETWEEN and IN arguments containing volatile expressions
* http://archives.postgresql.org/message-id/4D95B605.2020709@enterprisedb.com
}}

{{TodoItem
|Fix nested CASE-WHEN constructs
* http://archives.postgresql.org/message-id/4DDCEEB8.50602@enterprisedb.com
}}

=== CREATE ===
{{TodoSubsection}}

{{TodoItem
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}

{{TodoItem
|Have WITH CONSTRAINTS also create constraint indexes
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]
}}

{{TodoItem
|Move NOT NULL constraint information to pg_constraint
|Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. Another issue is that we should probably force NOT NULL to be propagated from parent tables to children, just as CHECK constraints are. (But then does dropping PRIMARY KEY affect children?)
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg01223.php
}}

{{TodoItem
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]
}}

{{TodoItem
|Add CREATE SCHEMA ... LIKE that copies a schema}}

{{TodoItem
|Fix CREATE OR REPLACE FUNCTION to not leave objects depending on the function in inconsistent state
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]
}}

{{TodoItem
|Allow temporary tables to exist as empty by default in all sessions
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php <nowiki>idea: global temp tables</nowiki>]
* [http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php <nowiki>Re: idea: global temp tables</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg01098.php <nowiki>global temporary tables</nowiki>]
}}

{{TodoItem
|Allow the creation of "distinct" types
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php <nowiki>Distinct types</nowiki>]
}}

{{TodoItem
|Consider analyzing temporary tables when they are first used in a query
|Autovacuum cannot analyze or vacuum temporary tables.
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php <nowiki>autovacuum and temp tables support</nowiki>]
}}

{{TodoItem
|Allow an unlogged table to be changed to logged
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00437.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00323.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00237.php
}}

{{TodoEndSubsection}}

=== UPDATE ===
{{TodoSubsection}}

{{TodoItem
|<nowiki>Allow UPDATE tab SET ROW (col, ...) = (SELECT...)</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg01308.php <nowiki>Re: [PATCHES] extension for sql update</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00865.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php <nowiki>Re: UPDATE using sub selects</nowiki>]
}}

{{TodoItem
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00016.php <nowiki>Re: Do we need a TODO? (was Re: Concurrently updating anupdatable view)</nowiki>]
}}

{{TodoItem
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows
|This is related to the previous item, which questions whether it even has the right semantics
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]
}}

{{TodoEndSubsection}}

=== ALTER ===
{{TodoSubsection}}

{{TodoItem
|Have ALTER TABLE RENAME of a SERIAL column rename the sequence
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItem
|Have ALTER SEQUENCE RENAME rename the sequence name stored in the sequence table
* [http://archives.postgresql.org/pgsql-bugs/2007-09/msg00092.php <nowiki>BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00007.php <nowiki>Re: BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItemEasy
|Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME or ALTER TABLE RENAME CONSTRAINT
* [http://archives.postgresql.org/pgsql-patches/2006-02/msg00168.php <nowiki>ALTER CONSTRAINT RENAME patch reverted</nowiki>]
}}

{{TodoItem
|Add ALTER DOMAIN to modify the underlying data type}}

{{TodoItem
|Allow ALTER TABLESPACE to move the tablespace to different directories}}

{{TodoItem
|Allow moving system tables to other tablespaces, where possible
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}

{{TodoItem
|Have ALTER INDEX update the name of a constraint using that index}}

{{TodoItem
|Allow column display reordering by recording a display, storage, and permanent id for every column?
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php <nowiki>Column reordering in pg_dump</nowiki>]
}}

{{TodoItem
|Allow deactivating (and reactivating) indexes via ALTER TABLE
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01191.php
}}

{{TodoEndSubsection}}

=== CLUSTER ===
{{TodoSubsection}}

{{TodoItem
|Automatically maintain clustering on a table
|This might require some background daemon to maintain clustering during periods of low usage. It might also require tables to be only partially filled for easier reorganization. Another idea would be to create a merged heap/index data file so an index lookup would automatically access the heap data too. A third idea would be to store heap rows in hashed groups, perhaps using a user-supplied hash function.
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]
* http://community.enterprisedb.com/git/
* [http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php <nowiki>Re: maintain_cluster_order_v5.patch</nowiki>]
}}

{{TodoEndSubsection}}

=== COPY ===
{{TodoSubsection}}

{{TodoItem
|Allow COPY to report error lines and continue
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure.
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]
}}

{{TodoItem
|Allow COPY FROM to create index entries in bulk
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]
}}

{{TodoItem
|Allow COPY in CSV mode to control whether a quoted zero-length string is treated as NULL
|Currently this is always treated as a zero-length string, which generates an error when loading into an integer column
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php <nowiki>Re: [PATCHES] allow CSV quote in NULL</nowiki>]
}}

{{TodoItem
|Improve COPY performance
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01882.php
}}

{{TodoItem
|Allow COPY to report errors sooner
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]
}}

{{TodoItem
|Allow COPY to handle other number formats
|E.g. the German notation. Best would be something like WITH DECIMAL ','.
}}

{{TodoItem
|Allow a stalled COPY to exit if the backend is terminated
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00067.php <nowiki>Re: possible bug not in open items</nowiki>]
}}

{{TodoEndSubsection}}

=== GRANT/REVOKE ===
{{TodoSubsection}}

{{TodoItem
|Allow SERIAL sequences to inherit permissions from the base table?}}

{{TodoItem
|Allow dropping of a role that has connection rights
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php <nowiki>DROP ROLE dependency tracking ...</nowiki>]
}}
{{TodoEndSubsection}}

=== DECLARE CURSOR ===
{{TodoSubsection}}

{{TodoItem
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}

{{TodoItem
|Provide some guarantees about the behavior of cursors that invoke volatile functions
* [http://archives.postgresql.org/message-id/20997.1244563664@sss.pgh.pa.us Re: Cursor with hold emits the same row more than once across commits in 8.3.7]
}}

{{TodoEndSubsection}}

=== INSERT ===
{{TodoSubsection}}

{{TodoItem
|Allow INSERT/UPDATE of the system-generated oid value for a row}}

{{TodoItem
|In rules, allow VALUES() to contain a mixture of 'old' and 'new' references}}

{{TodoEndSubsection}}

=== SHOW/SET ===
{{TodoSubsection}}

{{TodoItem
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}

{{TodoItem
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count
* [http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php <nowiki>Re: [ADMIN] shared_buffers and shmmax</nowiki>]
}}

{{TodoEndSubsection}}

=== ANALYZE ===
{{TodoSubsection}}

{{TodoItem
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}

{{TodoItem
|Have EXPLAIN ANALYZE report rows as floating-point numbers
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg01363.php <nowiki>explain analyze rows=%.0f</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00108.php <nowiki>Re: explain analyze rows=%.0f</nowiki>]
}}

{{TodoItem
|Improve how ANALYZE computes in-doubt tuples
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]
}}

{{TodoEndSubsection}}

=== Window Functions ===
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.
{{TodoSubsection}}
{{TodoItem
|Support creation of user-defined window functions
|We have the ability to create new window functions written in C. Is it
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}

{{TodoItem
|Implement full support for window framing clauses
|In addition to done clauses described in the [http://developer.postgresql.org/pgdocs/postgres/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS latest doc], these clauses are not implemented yet.
* RANGE BETWEEN ... PRECEDING/FOLLOWING
* EXCLUDE
}}

{{TodoItem
|Investigate tuplestore performance issues
|The tuplestore_in_memory() thing is just a band-aid, we ought to try to solve it properly. tuplestore_advance seems like a weak spot as well.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php <nowiki>tuplestore potential performance problem</nowiki>]
}}

{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}

{{TodoItem
|Teach planner to evaluate multiple windows in the optimal order
|Currently windows are always evaluated in the query-specified order.
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64
}}

{{TodoItem
|Implement DISTINCT clause in window aggregates
|Some proprietary RDBMSs have implemented it already, so it helps with porting from those.}}

{{TodoEndSubsection}}

== Integrity Constraints ==
=== Keys ===

{{TodoSubsection}}

{{TodoItem
|Improve deferrable unique constraints for cases with many conflicts
|The current implementation fires a trigger for each potentially conflicting row. This might not scale well for an update that changes many key values at once.
}}

{{TodoEndSubsection}}

=== Referential Integrity ===
{{TodoSubsection}}

{{TodoItem
|Add MATCH PARTIAL referential integrity}}

{{TodoItem
|Change foreign key constraint for array -> element to mean element in array?
* [http://archives.postgresql.org/pgsql-hackers/2010-10/msg01814.php <nowiki>foreign keys for array/period contains relationships</nowiki>]
}}

{{TodoItem
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]
}}

{{TodoItem
|Optimize referential integrity checks
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php <nowiki>Can't ri_KeysEqual() consider two nulls as equal?</nowiki>]
}}

{{TodoEndSubsection}}

== Server-Side Languages ==

{{TodoItem
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}

{{TodoItem
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}

{{TodoItem
|Add more fine-grained specification of functions taking arbitrary data types
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php <nowiki>RfD: more powerful "any" types</nowiki>]
}}

{{TodoItem
|Implement stored procedures
|This might involve the control of transaction state and the return of multiple result sets
* [http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php <nowiki>PL/pgSQL stored procedure returning multiple result sets (SELECTs)?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php
* [http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php <nowiki>Gathering specs and discussion on feature (post 9.1)</nowiki>]
}}

{{TodoItem
|Allow holdable cursors in SPI}}

{{TodoItemEasy
|Add SPI_gettypmod() to return a field's typemod from a TupleDesc
* http://archives.postgresql.org/pgsql-hackers/2005-11/msg00250.php
}}

=== SQL-Language Functions ===
{{TodoSubsection}}

{{TodoItem
|Allow SQL-language functions to reference parameters by parameter name
|Currently SQL-language functions can only refer to dollar parameters, e.g. $1
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01479.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01519.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00221.php
}}

{{TodoItem
|Rethink query plan caching and timing of parse analysis within SQL-language functions
|They should work more like plpgsql functions do ...
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00078.php <nowiki>Re: BUG #6019: invalid cached plan on inherited table</nowiki>]
}}

{{TodoEndSubsection}}

=== PL/pgSQL ===
{{TodoSubsection}}

{{TodoItem
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}

{{TodoItem
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki>
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
}}

{{TodoItem
|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.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]
}}

{{TodoItem
|Consider keeping separate cached copies when search_path changes
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]
}}

{{TodoItem
|Improve handling of NULL row values vs. NULL rows
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php <nowiki>Null row vs. row of nulls in plpgsql</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01973.php
}}

{{TodoItem
|Improve PERFORM handling of WITH queries or document limitation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00309.php
}}

{{TodoEndSubsection}}

=== PL/Perl ===
{{TodoSubsection}}

{{TodoItem
|Allow regex operations in plperl using UTF8 characters in non-UTF8 encoded databases}}

{{TodoEndSubsection}}

=== PL/Python ===
{{TodoSubsection}}

{{TodoItem
|Develop a trusted variant of PL/Python.}}

{{TodoItem
|Create a new restricted execution class that will allow passing function arguments in as locals. Passing them as globals means functions cannot be called recursively.
* [http://archives.postgresql.org/pgsql-hackers/2011-02/msg01468.php <nowiki>Re: pl/python do not delete function arguments</nowiki>]
}}

{{TodoItem
|Add a DB-API compliant interface on top of the SPI interface}}

{{TodoItem
|For functions returning a setof record with a composite type, cache the I/O functions for the composite type
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02007.php
}}

{{TodoItem
|Fix loss of information during conversion of numeric type to Python float}}

{{TodoEndSubsection}}

=== PL/Tcl ===
{{TodoSubsection}}

{{TodoItem
|Add table function support}}

{{TodoItem
|Check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, and SPI calls.}}

{{TodoEndSubsection}}

== Clients ==

{{TodoItem
|Add a function like pg_get_indexdef() that report more detailed index information
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00166.php <nowiki>BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)</nowiki>]
}}

{{TodoItem
|Split out pg_resetxlog output into pre- and post-sections
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php
}}

=== pg_ctl ===
{{TodoSubsection}}

{{TodoItemDone
|Allow pg_ctl to work properly with configuration files located outside the PGDATA directory
|pg_ctl can not read the pid file because it isn't located in the config directory but in the PGDATA directory. The solution is to allow pg_ctl to read and understand postgresql.conf to find the data_directory value.
* [http://archives.postgresql.org/pgsql-bugs/2009-10/msg00024.php <nowiki>BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory</nowiki>]
}}

{{TodoItem
|Modify pg_ctl behavior and exit codes to make it easier to write an LSB conforming init script
|It may be desirable to condition some of the changes on a command-line switch, to avoid breaking existing scripts. A Linux shell (sh) script is referenced which has been tested and seems to provide a high degree of conformance in multiple environments. Study of this script might suggest areas where pg_ctl could be modified to make writing an LSB conforming script easier; however, some aspects of that script would be unnecessary with other suggested changes to pg_ctl, and discussion on the lists did not reach consensus on support for all aspects of this script. Further discussion of particular changes is needed before beginning any work.
* [[Lsb_conforming_init_script|LSB conforming init script]]
These threads should be studied for other ideas on improvements:
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01390.php <nowiki>We should Axe /contrib/start-scripts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01843.php <nowiki>Linux LSB init script</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00008.php <nowiki>Re: Linux LSB init script</nowiki>]
}}

{{TodoItem
|Improve pg_ctl's detection of running postmasters
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00000.php
* http://archives.postgresql.org/pgsql-committers/2011-06/msg00001.php
}}

{{TodoEndSubsection}}

=== psql ===
{{TodoSubsection}}

{{TodoItem
|Have psql \ds show all sequences and their settings
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00916.php <nowiki>Re: TODO item: Have psql show current values for a sequence</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00401.php <nowiki>Quick patch: Display sequence owner</nowiki>]
}}

{{TodoItem
|Have \d on a sequence indicate if the sequence is owned by a table}}

{{TodoItem
|Move psql backslash database information into the backend, use mnemonic commands?
|This would allow non-psql clients to pull the same information out of the database as psql.
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]
}}

{{TodoItem
|Make psql's \d commands more consistent in their handling of schemas
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php <nowiki>Re: psql and schemas</nowiki>]
}}

{{TodoItem
|Make psql's \d commands distinguish default privileges from no privileges
|ACL displays were visibly different for the two cases before we "improved" them by using array_to_string.
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00082.php <nowiki>BUG #6021: There is no difference between default and empty access privileges with \dp</nowiki>]
}}

{{TodoItem
|Consistently display privilege information for all objects in psql}}

{{TodoItem
|Add "auto" expanded mode that outputs in expanded format if "wrapped" mode can't wrap the output to the screen width
|Consider using auto-expanded mode for backslash commands like \df+.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00417.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01638.php
}}

{{TodoItem
|Prevent tab completion of SET TRANSACTION from querying the database and therefore preventing the transaction isolation level from being set.
|Currently SET <tab> causes a database lookup to check all supported session variables. This query causes problems because setting the transaction isolation level must be the first statement of a transaction.}}

{{TodoItemEasy
|\s without arguments (display history) fails with libedit, doesn't use pager either
* [http://archives.postgresql.org/pgsql-bugs/2011-06/msg00114.php <nowiki> psql \s not working - OS X</nowiki>]
}}

{{TodoItem
|Add a \set variable to control whether \s displays line numbers
|Another option is to add \# which lists line numbers, and allows command execution.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]
}}

{{TodoItem
|Include the symbolic SQLSTATE name in verbose error reports
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]
}}

{{TodoItem
|Add prompt escape to display the client and server versions
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00310.php <nowiki>WIP patch for TODO Item: Add prompt escape to display the client and server versions</nowiki>]
}}

{{TodoItem
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.
|Currently, "wrapped" format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}

{{TodoItem
|Support the ReST table output format
|Details about the ReST format: http://docutils.sourceforge.net/rst.html#reference-documentation
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg01007.php <nowiki>Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00518.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00609.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
}}

{{TodoItem
|Add option to print advice for people familiar with other databases
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php <nowiki>MySQL-ism help patch for psql</nowiki>]
}}

{{TodoItemDone
|\dd is missing comments for several types of objects
|Comments are not handled at all for some object types, and are handled by both \dd and the individual backslash command for others. Consider a system view like pg_comments to manage this mess.
* [http://archives.postgresql.org/pgsql-general/2009-09/msg00199.php <nowiki>comment on constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php <nowiki>pg_comments</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2011-05/msg00885.php <nowiki>patch: Allow \dd to show constraint comments</nowiki>]
}}

{{TodoItem
|Add ability to edit views with \ev
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00023.php <nowiki>Adding \ev view editor?</nowiki>]
}}

{{TodoItem
|Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php
}}

{{TodoItem
|Prevent psql from sending remaining single-line multi-statement queries after reconnecting
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php
}}

{{TodoItemEasy
|Add \i option to bring in the specified file as a quoted literal
|This would be useful for creating functions and other areas. Details still need to be worked out.
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00016.php
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00020.php
}}

{{TodoItem
|Consider having psql -c read .psqlrc, for consistency
|psql -f already reads .psqlrc
}}

{{TodoItem
|Allow processing of multiple -f (file) options
}}

{{TodoItem
|Improve line drawing characters
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00386.php
}}

{{TodoItem
|Consider improving the continuation prompt
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01772.php
}}

{{TodoEndSubsection}}

=== pg_dump / pg_restore ===
{{TodoSubsection}}

{{TodoItemEasy
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}

{{TodoItem
|Add pg_dumpall custom format dumps?
* [http://archives.postgresql.org/pgsql-general/2010-05/msg00509.php pg_dumpall custom format]
|}}

{{TodoItem
|Avoid using platform-dependent locale names in pg_dumpall output
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us
}}

{{TodoItem
|Allow selection of individual object(s) of all types, not just tables}}

{{TodoItem
|In a selective dump, allow dumping of an object and all its dependencies}}

{{TodoItem
|Add options like pg_restore -l and -L to pg_dump}}

{{TodoItem
|Add support for multiple pg_restore -t options, like pg_dump
|pg_restore's -t switch is less useful than pg_dump's in quite a few ways: no multiple switches, no pattern matching, no ability to pick up indexes and other dependent items for a selected table. It should be made to handle this switch just like pg_dump does.}}

{{TodoItem
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}

{{TodoItem
|Allow pg_dump --clean to drop roles that own objects or have privileges
|tgl says: if this is about pg_dumpall, it's done as of 8.4. If it's really about pg_dump, what does it mean? pg_dump has no business dropping roles.}}

{{TodoItem
|Allow pg_dump to utilize multiple CPUs and I/O channels by dumping multiple objects simultaneously
|The difficulty with this is getting multiple dump processes to produce a single dump output file. It also would require several sessions to share the same snapshot.
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00040.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02454.php
}}

{{TodoItem
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}

{{TodoItem
|Remove support for dumping from pre-7.3 servers
|In 7.3 and later, we can get accurate dependency information from the server. pg_dump still contains a lot of crufty code
to try to deal with the lack of dependency info in older servers, but the usefulness of maintaining that code grows small.}}

{{TodoItem
|Allow pre/data/post files when schema and data are dumped separately, for performance reasons
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00185.php <nowiki>Re: pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00821.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
}}

{{TodoItem
|Refactor handling of database attributes between pg_dump and pg_dumpall
|Currently only pg_dumpall emits database attributes, such as ALTER DATABASE SET commands and database-level GRANTs.
Many people wish that pg_dump would do that. One proposal is to let pg_dump issue such commands if the -C switch was used,
but it's unclear whether that will satisfy the demand.
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2010-05/msg00010.php summary of the issues]
}}

{{TodoItem
|Change pg_dump so that a comment on the dumped database is applied to the loaded database, even if the database has a different name.
|This will require new backend syntax, perhaps COMMENT ON CURRENT DATABASE. This is related to the previous item.}}

{{TodoItem
|Allow parallel restore of tar dumps
* [http://archives.postgresql.org/pgsql-hackers/2009-02/msg01154.php <nowiki>Re: parallel restore</nowiki>]
}}

{{TodoItemDone
|Allow pg_dumpall to output restorable ALTER USER/DATABASE SET settings
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00916.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00394.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02359.php
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg00489.php
}}

{{TodoEndSubsection}}

=== ecpg ===
{{TodoSubsection}}

{{TodoItem
|Docs
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}

{{TodoItem
|Solve cardinality > 1 for input descriptors / variables?}}

{{TodoItem
|Add a semantic check level, e.g. check if a table really exists}}

{{TodoItem
|fix handling of DB attributes that are arrays}}

{{TodoItem
|Fix nested C comments}}

{{TodoItemEasy
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}

{{TodoItem
|Make SET CONNECTION thread-aware, non-standard?}}

{{TodoItem
|Allow multidimensional arrays}}

{{TodoItem
|Implement COPY FROM STDIN}}

{{TodoItem
|Provide a way to specify size of a bytea parameter
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]
}}

{{TodoItemEasy
|Fix small memory leaks in ecpg
|Memory leaks in a short running application like ecpg are not really a problem, but make debugging more complicated}}

{{TodoItem
|Allow reuse of cursor name variables
* [http://archives.postgresql.org/message-id/20100329113435.GA3430@feivel.credativ.lan <nowiki>Problems with variable cursorname in ecpg</nowiki>]
}}

{{TodoEndSubsection}}

=== libpq ===
{{TodoSubsection}}

{{TodoItem
|Prevent PQfnumber() from lowercasing unquoted column names
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}

{{TodoItem
|Allow statement results to be automatically batched to the client
|Currently all statement results are transferred to the libpq client before libpq makes the results available to the application. This feature would allow the application to make use of the first result rows while the rest are transferred, or held on the server waiting for them to be requested by libpq. One complexity is that a statement like SELECT 1/col could error out mid-way through the result set.}}

{{TodoItem
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]
}}

{{TodoItem
|Add PQexecf() that allows complex parameter substitution
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]
}}

{{TodoItem
|Add SQLSTATE and severity to errors generated within libpq itself
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01425.php
}}

{{TodoItem
|Add support for interface/ipaddress binding to libpq
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php <nowiki>SR/libpq - outbound interface/ipaddress binding</nowiki>]
}}

{{TodoEndSubsection}}

== Triggers ==

{{TodoItem
|Improve storage of deferred trigger queue
|Right now all deferred trigger information is stored in backend memory. This could exhaust memory for very large trigger queues. This item involves dumping large queues into files, or doing some kind of join to process all the triggers, some bulk operation, or a bitmap.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php <nowiki>Scaling up deferred unique checks and the after trigger queue</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00023.php
}}

{{TodoItem
|Allow triggers to be disabled in only the current session.
|This is currently possible by starting a multi-statement transaction, modifying the system tables, performing the desired SQL, restoring the system tables, and committing the transaction. ALTER TABLE ... TRIGGER requires a table lock so it is not ideal for this usage.}}

{{TodoItem
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}

{{TodoItem
|Allow statement-level triggers to access modified rows}}

{{TodoItem
|When statement-level triggers are defined on a parent table, have them fire only on the parent table, and fire child table triggers only where appropriate
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php <nowiki>Statement-level triggers and inheritance</nowiki>]
}}

{{TodoItem
|Allow AFTER triggers on system tables
|System tables are modified in many places in the backend without going through the executor and therefore not causing triggers to fire. To complete this item, the functions that modify system tables will have to fire triggers.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01665.php
* http://wiki.postgresql.org/wiki/DDL_Triggers
}}

{{TodoItem
|Tighten trigger permission checks
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]
}}

{{TodoItem
|Allow BEFORE INSERT triggers on views
* [http://archives.postgresql.org/pgsql-general/2007-02/msg01466.php <nowiki>Re: Why can't I put a BEFORE EACH ROW trigger on a view?</nowiki>]
}}

{{TodoItem
|Add database and transaction-level triggers
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]
}}

{{TodoItem
|Reduce locking requirements for creating a trigger
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php <nowiki>Re: Change lock requirements for adding a trigger</nowiki>]
}}

{{TodoItem
|Avoid requirement for "AFTER" trigger functions to return a value
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02384.php
}}

== Inheritance ==

{{TodoItem
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys
* [http://archives.postgresql.org/pgsql-hackers/2010-05/msg00285.php <nowiki>Partitioning/inherited tables vs FKs</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00039.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00305.php
}}

{{TodoItem
|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.}}

{{TodoItem
|Determine whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY). If yes, implement it.}}

{{TodoItem
|ALTER TABLE variants sometimes support recursion and sometimes not, but this is poorly/not documented, and the ONLY marker would then be silently ignored. Clarify the documentation, and reject ONLY if it is not supported.}}

== Indexes ==

{{TodoItem
|Prevent index uniqueness checks when UPDATE does not modify the column
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.
However, HOT already short-circuits this in common cases, so more work might not be helpful.}}

{{TodoItem
|Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes
|Such indexes could be more compact if there are only a few distinct values. Such indexes can also be compressed. Keeping such indexes updated can be costly.
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php <nowiki>Bitmap Indexes: request for feedback</nowiki>]
* http://archives.postgresql.org/message-id/800923.27831.qm@web29010.mail.ird.yahoo.com
}}

{{TodoItem
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02179.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00459.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02054.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01731.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00894.php
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00679.php
}}

{{TodoItem
|Consider having a larger statistics target for indexed columns and expression indexes.
}}

{{TodoItem
|Consider smaller indexes that record a range of values per heap page, rather than having one index entry for every heap row
|This is useful if the heap is clustered by the indexed values.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00341.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01264.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00465.php <nowiki>Grouped Index Tuples / Clustered Indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php <nowiki>Bitmapscan changes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php <nowiki>Re: GIT patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php <nowiki>Re: Index Tuple Compression Approach?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php <nowiki>Re: Index AM change proposals, redux</nowiki>]
}}

{{TodoItem
|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.
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]
}}

{{TodoItem
|Allow multiple indexes to be created concurrently, ideally via a single heap scan
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00093.php
}}

{{TodoItem
|Consider sorting entries before inserting into btree index
* [http://archives.postgresql.org/pgsql-general/2008-01/msg01010.php <nowiki>Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?</nowiki>]
}}

{{TodoItem
|Allow index scans to return matching index keys, not just the matching heap locations
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01657.php <nowiki>Re: Is this TODO item done?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01477.php <nowiki>Index-only quals</nowiki>]
}}

{{TodoItem
|Allow creation of an index that can do comparisons to test if a value is between two column values
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00757.php <nowiki>Proposal: temporal extension "period" data type</nowiki>]
}}

{{TodoItem
|Consider using "effective_io_concurrency" for index scans
* Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.
}}

{{TodoItem
|Fix problem with btree page splits during checkpoints
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00052.php
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00184.php
}}

=== GIST ===
{{TodoSubsection}}

{{TodoItem
|Add more GIST index support for geometric data types}}

{{TodoItem
|Allow GIST indexes to create certain complex index types, like digital trees (see Aoki)}}

{{TodoItem
|Fix performance issues in contrib/seg and contrib/cube GiST support
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00069.php <nowiki>Re: GiST index performance</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2009-06/msg00068.php <nowiki>GiST index performance</nowiki>]
}}

{{TodoEndSubsection}}

=== Hash ===
{{TodoSubsection}}

{{TodoItem
|Add UNIQUE capability to hash indexes}}

{{TodoItem
|Add hash WAL logging for crash recovery
* http://archives.postgresql.org/pgsql-performance/2011-09/msg00196.php
}}

{{TodoItem
|Allow multi-column hash indexes}}

{{TodoEndSubsection}}

== Sorting ==

{{TodoItem
|Consider whether duplicate keys should be sorted by block/offset
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]
}}

{{TodoItem
|Consider being smarter about memory and external files used during sorts
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php <nowiki>Re: Sorting Improvements for 8.4</nowiki>]
}}

{{TodoItem
|Consider detoasting keys before sorting}}

{{TodoItem
|Allow sorts to use more available memory
* http://archives.postgresql.org/pgsql-hackers/2007-11/msg01026.php
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01123.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg01957.php
}}

== Fsync ==

{{TodoItem
|Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether fsync does anything
|Ideally this requires a separate test program like /contrib/pg_test_fsync that can be run at initdb time or optionally later.}}

{{TodoItem
|Consider sorting writes during checkpoint
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php <nowiki>Re: Sorting writes during checkpoint</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg02012.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00278.php
}}

== Cache Usage ==

{{TodoItemDone
|Speed up COUNT(*)
|We could use a fixed row count and a +/- count to follow MVCC visibility rules, or a single cached value could be used and invalidated if anyone modifies the table. Another idea is to get a count directly from a unique index, but for this to be faster than a sequential scan it must avoid access to the heap to obtain tuple visibility information. Note that the index-only scans feature is now implemented which now dramatically speeds up some COUNT(*) cases.
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItem
|Provide a way to calculate an "estimated COUNT(*)"
|Perhaps by using the optimizer's cardinality estimates or random sampling.
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php <nowiki>Re: Improving count(*)</nowiki>]
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItemDone
|Allow data to be pulled directly from indexes
|Currently indexes do not have enough tuple visibility information to allow data to be pulled from the index without also accessing the heap. The idea is to use the visibility map used for vacuum to avoid heap lookups on pages where all tuples are visible.
* [http://wiki.postgresql.org/wiki/Index-only_scans Index-Only Scans wiki]
}}

{{TodoItem
|Consider automatic caching of statements at various levels:
* Parsed query tree
* Query execute plan
* Query results

:
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]
}}

{{TodoItem
|Consider increasing internal areas (NUM_CLOG_BUFFERS) when shared buffers is increased
* [http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php <nowiki>Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php <nowiki>clog_buffers to 64 in 8.3?</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php <nowiki>CLOG Patch</nowiki>]
}}

{{TodoItem
|Consider decreasing the amount of memory used by PrivateRefCount
|
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php <nowiki>PrivateRefCount (for 8.3)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php <nowiki>Re: PrivateRefCount (for 8.3)</nowiki>]
}}

{{TodoItem
|Consider allowing higher priority queries to have referenced buffer cache pages stay in memory longer
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]
}}

== Vacuum ==

{{TodoItem
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]
}}

{{TodoItem
|Allow concurrent inserts to use recently created pages rather than creating new ones
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php
}}

{{TodoItem
|Consider having single-page pruning update the visibility map
* <nowiki>https://commitfest.postgresql.org/action/patch_view?id=75</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php <nowiki>Re: visibility maps and heap_prune</nowiki>]
}}

{{TodoItem
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]
}}

{{TodoItem
|Bias FSM towards returning free space near the beginning of the heap file, in hopes that empty pages at the end can be truncated by VACUUM
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php <nowiki>FSM search modes</nowiki>]
}}

{{TodoItem
|Consider a more compact data representation for dead tuple locations within VACUUM
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php <nowiki>Re: Have vacuum emit a warning when it runs out of maintenance_work_mem</nowiki>]
}}

{{TodoItem
|Provide more information in order to improve user-side estimates of dead space bloat in relations
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]
}}

{{TodoItem
|Improve locking behaviour of vacuum during trailing page truncation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00319.php
* http://archives.postgresql.org/message-id/4D8DF88E.7080205@Yahoo.com
}}

{{TodoItem
|Reduce the number of table scans performed by vacuum
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00605.php
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php
}}

=== Auto-vacuum ===
{{TodoSubsection}}

{{TodoItemEasy
|Issue log message to suggest VACUUM FULL if a table is nearly empty?}}

{{TodoItem
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can do that.
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]
}}

{{TodoItem
|Prevent autovacuum from running if an old transaction is still running from the last vacuum
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]
}}

{{TodoItem
|Have autoanalyze of parent tables occur when child tables are modified
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php
* http://archives.postgresql.org/pgsql-performance/2010-10/msg00271.php
}}

{{TodoEndSubsection}}

== Locking ==

{{TodoItem
|Fix priority ordering of read and write light-weight locks
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php <nowiki>lwlocks and starvation</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php <nowiki>Re: lwlocks and starvation</nowiki>]
}}

{{TodoItem
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]
}}

{{TodoItem
|Allow UPDATEs on only non-referential integrity columns not to conflict with referential integrity locks
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php <nowiki>Referential Integrity and SHARE locks</nowiki>]
}}

{{TodoItem
|Add idle_in_transaction_timeout GUC so locks are not held for long periods of time}}

{{TodoItem
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]
}}

{{TodoItem
|Detect deadlocks involving LockBufferForCleanup()
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
}}

{{TodoItem
|Allow finer control over who is cancelled in a deadlock
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01727.php
}}

{{TodoItem
|Consider a lock timeout parameter
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00485.php <nowiki>SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5</nowiki>]
}}

{{TodoItem
|Reduce number of unnecessary false positives in Serializable Snapshot Isolation
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00609.php <nowiki>SSI heap_insert and page-level predicate locks</nowiki>]
}}

== Startup Time Improvements ==

{{TodoItem
|Experiment with multi-threaded backend for backend creation
|This would prevent the overhead associated with process creation. Most operating systems have trivial process creation time compared to database startup overhead, but a few operating systems (Win32, Solaris) might benefit from threading. Also explore the idea of a single session using multiple threads to execute a statement faster.}}

{{TodoItem
|Allow backends to change their database without restart
|This allows for faster server startup.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00843.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00336.php
}}

== Write-Ahead Log ==

{{TodoItem
|Eliminate need to write full pages to WAL before page modification
|Currently, to protect against partial disk page writes, we write full page images to WAL before they are modified so we can correct any partial page writes during recovery. These pages can also be eliminated from point-in-time archive files.
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01191.php
}}

{{TodoItem
|When full page writes are off, write CRC to WAL and check file system blocks on recovery
|If CRC check fails during recovery, remember the page in case a later CRC for that page properly matches.}}

{{TodoItem
|Write full pages during file system write and not when the page is modified in the buffer cache
|This allows most full page writes to happen in the background writer. It might cause problems for applying WAL on recovery into a partially-written page, but later the full page will be replaced from WAL.}}

{{TodoItem
|Reduce WAL traffic so only modified values are written rather than entire rows
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php <nowiki>Reduction in WAL for UPDATEs</nowiki>]
}}

{{TodoItem
|Allow WAL information to recover corrupted pg_controldata
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]
}}

{{TodoItem
|Find a way to reduce rotational delay when repeatedly writing last WAL page
|Currently fsync of WAL requires the disk platter to perform a full rotation to fsync again. One idea is to write the WAL to different offsets that might reduce the rotational delay.
* [http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php <nowiki>500 tpsQL + WAL log implementation</nowiki>]
}}

{{TodoItem
|Speed WAL recovery by allowing more than one page to be prefetched
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay.
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]
}}

{{TodoItem
|Improve WAL concurrency by increasing lock granularity
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]
}}

{{TodoItem
|Be more aggressive about creating WAL files
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php <nowiki>Re: PANIC caused by open_sync on Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-07/msg01075.php <nowiki>PreallocXlogFiles</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2005-04/msg00556.php <nowiki>WAL/PITR additional items</nowiki>]
}}

{{TodoItem
|Have resource managers report the duration of their status changes
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]
}}

{{TodoItem
|Move pgfoundry's xlogdump to /contrib and have it rely more closely on the WAL backend code
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php <nowiki>xlogdump</nowiki>]
}}

{{TodoItem
|Close deleted WAL files held open in *nix by long-lived read-only backends
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]
}}

== Optimizer / Executor ==

{{TodoItem
|Improve selectivity functions for geometric operators}}

{{TodoItem
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]
}}

{{TodoItem
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG}}

{{TodoItem
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}

{{TodoItem
|Consider compressed annealing to search for query plans
|This might replace GEQO.
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us
}}

{{TodoItem
|Improve use of expression indexes for ORDER BY
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php <nowiki>Resjunk sort columns, Heikki's index-only quals patch, and bug #5000</nowiki>]
}}

{{TodoItem
|Modify the planner to better estimate caching effects
* http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php
}}

{{TodoItem
|Allow shared buffer cache contents to affect index cost computations
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php
}}

=== Hashing ===
{{TodoSubsection}}

{{TodoItem
|Consider using a hash for joining to a large IN (VALUES ...) list
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]
}}

{{TodoItem
|Allow single batch hash joins to preserve outer pathkeys
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|"lazy" hash tables - look up only the tuples that are actually requested
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid building the same hash table more than once during the same query
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid hashing for distinct and then re-hashing for hash join
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoEndSubsection}}

== Background Writer ==

{{TodoItem
|Consider having the background writer update the transaction status hint bits before writing out the page
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.}}

{{TodoItem
|Consider adding buffers the background writer finds reusable to the free list
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
}}

{{TodoItem
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
}}

{{TodoItem
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]
}}

{{TodoItem
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]
}}

== Concurrent Use of Resources ==

{{TodoItem
|Do async I/O for faster random read-ahead of data
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-09/msg00255.php <nowiki>Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-01/msg00170.php <nowiki>Bitmap index scan preread using posix_fadvise (Was: There's random access and then there's random access)</nowiki>]
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]
}}

{{TodoItem
|Experiment with multi-threaded backend for better I/O utilization
|This would allow a single query to make use of multiple I/O channels simultaneously. One idea is to create a background reader that can pre-fetch sequential and index scan pages needed by other backends. This could be expanded to allow concurrent reads from multiple devices in a partitioned table.
* http://archives.postgresql.org/pgsql-performance/2011-02/msg00123.php
}}

{{TodoItem
|Experiment with multi-threaded backend for better CPU utilization
|This would allow several CPUs to be used for a single query, such as for sorting or query execution.
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00945.php <nowiki>Multi CPU Queries - Feedback and/or suggestions wanted!</nowiki>]
}}

{{TodoItem
|SMP scalability improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

== TOAST ==

{{TodoItem
|Allow user configuration of TOAST thresholds
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]
}}

{{TodoItem
|Reduce unnecessary cases of deTOASTing
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]
}}

{{TodoItem
|Reduce costs of repeat de-TOASTing of values
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]
}}

== Monitoring ==
{{TodoItem
|Expand pg_stat_activity for easier integration with monitoring tools
|* http://archives.postgresql.org/message-id/4DFA13A5.2060200@2ndQuadrant.com
}}

{{TodoItem
|Add column to pg_stat_activity that shows the progress of long-running commands like CREATE INDEX and VACUUM
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00203.php <nowiki>EXPLAIN progress info</nowiki>]
* The CLUSTER/VACUUM FULL implementation would also be useful to track this way
}}

{{TodoItem
|Have pg_stat_activity display query strings in the correct client encoding
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php <nowiki>pg_stats queries versus per-database encodings</nowiki>]
}}

{{TodoItemEasy
|Expose pg_controldata via an SQL interface
|Helpful for monitoring replicated databases
* http://archives.postgresql.org/message-id/4B901D73.8030003@agliodbs.com
* [http://archives.postgresql.org/message-id/4B959D7A.6010907@joeconway.com initial patch]
}}

== Miscellaneous Performance ==

{{TodoItem
|Use mmap() rather than SYSV for shared buffers?
|This would remove the requirement for SYSV SHM but would introduce portability issues. Anonymous mmap (or mmap to /dev/zero) is required to prevent I/O overhead. We could also consider mmap() for writing WAL.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00750.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00756.php
}}

{{TodoItem
|Rather than consider mmap()-ing in 8k pages, consider mmap()'ing entire files into a backend?
|Doing I/O to large tables would consume a lot of address space or require frequent mapping/unmapping. Extending the file also causes mapping problems that might require mapping only individual pages, leading to thousands of mappings. Another problem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk before WAL is written.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01239.php
}}

{{TodoItem
|Consider ways of storing rows more compactly on disk:
* Reduce the row header size?
* Consider reducing on-disk varlena length from four bytes to two because a heap row cannot be more than 64k in length}}

{{TodoItem
|Consider transaction start/end performance improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php <nowiki>Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

{{TodoItem
|Allow configuration of backend priorities via the operating system
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]
}}

{{TodoItem
|Consider increasing the minimum allowed number of shared buffers
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]
}}

{{TodoItem
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]
}}

{{TodoItem
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]
}}

{{TodoItem
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]
}}

{{TodoItem
|Sort large UPDATE/DELETEs so it is done in heap order
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]
}}

{{TodoItem
|Allow one transaction to see tuples using the snapshot of another transaction
|This would assist multiple backends in working together.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php <nowiki>Transaction Snapshot Cloning</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00260.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00466.php
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00684.php
}}

{{TodoItem
|Consider decreasing the I/O caused by updating tuple hint bits
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php
}}

{{TodoItem
|Avoid the requirement of freezing pages that are infrequently modified
|If all rows on a page are visible, it is possible to set a bit in the visibility map (once the visibility map is 100% reliable) and not need to freeze the page, avoiding a page rewrite
* http://archives.postgresql.org/message-id/4BF701CF.2090205@agliodbs.com
* http://archives.postgresql.org/pgsql-hackers/2010-06/msg00082.php
}}

{{TodoItem
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]
}}

{{TodoItem
|Restructure truncation logic to be more resistant to failure
|This also involves not writing dirty buffers for a truncated or dropped relation
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php
}}

{{TodoItem
|Consider adding logic to increase large tables by more than 8k
|This would reduce file system fragmentation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00337.php
}}

== Miscellaneous Other ==

{{TodoItem
|Deal with encoding issues for filenames in the server filesystem
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}
}}

{{TodoItem
|Deal with encoding issues in the output of localeconv()
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]
}}

{{TodoItem
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg00846.php <nowiki>patch - Report the schema along table name in a referential failure error message</nowiki>]
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]
}}

{{TodoItemEasy
| Provide [http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html#LIBPQ-CONNECT-FALLBACK-APPLICATION-NAME fallback_application_name] in contrib/pgbench, oid2name, and dblink.
* {{MessageLink|w2g9837222c1004070216u3bc46b3ahbddfdffdbfb46212@mail.gmail.com|fallback_application_name and pgbench}}
}}

{{TodoItem
|Add 64-bit support to /contrib/pgbench
* http://archives.postgresql.org/pgsql-hackers/2010-07/msg00153.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00705.php
}}

== Source Code ==

{{TodoItem
|Add use of 'const' for variables in source tree}}

{{TodoItemEasy
|Remove warnings created by -Wcast-align}}

{{TodoItem
|Move platform-specific ps status display info from ps_status.c to ports}}

{{TodoItem
|Add optional CRC checksum to heap and index pages
|One difficulty is how to prevent hint bit changes from affecting the computed CRC checksum.
* http://archives.postgresql.org/message-id/19934.1226601952%40sss.pgh.pa.us
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00002.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01028.php <nowiki>double-buffering page writes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00524.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01101.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00011.php <nowiki>Re: Block-level CRC checks</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00249.php
}}

{{TodoItem
|Consider a faster CRC32 algorithm
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php
}}

{{TodoItem
|Allow cross-compiling by generating the zic database on the target system}}

{{TodoItem
|Improve NLS maintenance of libpgport messages linked onto applications}}

{{TodoItem
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}

{{TodoItem
|Allow creation of universal binaries for Darwin
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]
}}

{{TodoItem
|Consider GnuTLS if OpenSSL license becomes a problem
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]
}}

{{TodoItem
|Consider making NAMEDATALEN more configurable in future releases}}

{{TodoItem
|Research use of signals and sleep wake ups
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]
}}

{{TodoItem
|Allow C++ code to more easily access backend code
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]
}}

{{TodoItem
|Consider simplifying how memory context resets handle child contexts
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]
}}

{{TodoItem
|Create three versions of libpgport to simplify client code
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]
}}

{{TodoItem
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]
}}

{{TodoItem
|Implement the non-threaded Avahi service discovery protocol
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]
}}

{{TodoItem
|Reduce data row alignment requirements on some 64-bit systems
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]
}}

{{TodoItem
|Restructure TOAST internal storage format for greater flexibility
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]
}}

{{TodoItem
| Add regression tests for pg_dump/restore
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01967.php <nowiki>"make install-check-pg_dump" target in src/regress]</nowiki>]
}}

{{TodoItem
| Research different memory allocation methods for lists
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php
}}

{{TodoItem
| Consider removing the attribute options cache
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00039.php
}}

{{TodoItem
| Restructure /contrib section
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00705.php
}}

=== /contrib/pg_upgrade ===
{{TodoSubsection}}

{{TodoItem
|Handle large object comments
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.
}}

{{TodoItem
|Consider using pg_depend for checking object usage in version.c
}}

{{TodoItem
|If reindex is necessary, allow it to be done in parallel with pg_dump custom format
}}

{{TodoItem
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary
|pg_class.oid is not preserved so schema.tablename must be used.
}}

{{TodoItem
|Improve testing, perhaps using the buildfarm
|The buildfarm has access to multiple versions of PostgreSQL.
}}

{{TodoItem
|Create machine-readable output of pg_controldata
|This would avoid parsing its output. The problem is we need pg_controldata output from both the old and new clusters so we would need to support both formats.
}}

{{TodoEndSubsection}}

=== Windows ===
{{TodoSubsection}}

{{TodoItem
|Remove configure.in check for link failure when cause is found}}

{{TodoItem
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}

{{TodoItem
|Allow psql to use readline once non-US code pages work with backslashes}}

{{TodoItem
|Fix problem with shared memory on the Win32 Terminal Server}}

{{TodoItem
|Improve signal handling
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]
}}

{{TodoItem
|Convert MSVC build system to remove most batch files
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]
}}

{{TodoItem
|Support pgxs when using MSVC}}

{{TodoItem
|Fix MSVC NLS support, like for to_char()
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php <nowiki>Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)</nowiki>]
}}

{{TodoItem
|Find a correct rint() substitute on Windows
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]
}}

{{TodoItem
|Fix global namespace issues when using multiple terminal server sessions
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}

{{TodoItem
|Change from the current autoconf/gmake build system to cmake
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01869.php <nowiki>About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)</nowiki>]
}}

{{TodoItem
|Improve consistency of path separator usage
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net
}}

{{TodoItem
|Fix cross-compiling on Windows
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php
}}

{{TodoItem
|Allow multiple Postgres clusters running on the same machine to distinguish themselves in the event log
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01297.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00574.php
}}

{{TodoEndSubsection}}

=== Wire Protocol Changes ===
{{TodoSubsection}}

{{TodoItem
|Allow dynamic character set handling}}

{{TodoItem
|Add decoded type, length, precision}}

{{TodoItem
|Mark result columns as known-not-null when possible
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]
}}

{{TodoItem
|Provide more control over planner treatment of statements being prepared}}

{{TodoItem
|Use compression?}}

{{TodoItem
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}

{{TodoItem
|Make sure upgrading to a 4.1 protocol version will actually work smoothly
* [http://archives.postgresql.org/message-id/28307.1318255008@sss.pgh.pa.us Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable]
}}

{{TodoEndSubsection}}

== Documentation ==

{{TodoItem
|Convert single quotes to apostrophes in the PDF documentation
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]
}}

{{TodoItem
|Provide a manpage for postgresql.conf
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Consider changing documentation format from SGML to XML
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]
* http://archives.postgresql.org/pgsql-docs/2011-04/msg00020.php
* http://wiki.postgresql.org/wiki/Switching_PostgreSQL_documentation_from_SGML_to_XML
}}

{{TodoItem
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com
}}

{{TodoItem
|Add diagrams to the documentation
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php
}}

== Exotic Features ==

{{TodoItem
|Add pre-parsing phase that converts non-ISO syntax to supported syntax
|This could allow SQL written for other databases to run without modification.}}

{{TodoItem
|Allow plug-in modules to emulate features from other databases}}

{{TodoItem
|Add features of Oracle-style packages
|A package would be a schema with session-local variables, public/private functions, and initialization functions. It is also possible to implement these capabilities in any schema and not use a separate "packages" syntax at all.
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]
}}

{{TodoItem
|Consider allowing control of upper/lower case folding of unquoted identifiers
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00849.php <nowiki>TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
}}

{{TodoItem
|Add autonomous transactions
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]
}}

{{TodoItem
|Give query progress indication
* [[Query progress indication]]
}}

{{TodoItem
|Rethink our type system
* [[Rethinking datatypes]]
}}

== Features We Do ''Not'' Want ==

The following features have been discussed ad nauseum on the PostgreSQL mailing lists and the consensus has been that the project is not interested in them. As such, if you are going to bring them up as potential features, you will want to be familiar with all of the arguments against these features which have been previously made over the years. If you decide to work on such features anyway, you should be aware that you face a higher-than-normal barrier to get the Project to accept them.

{{TodoItem
|All backends running as threads in a single process (not wanted)
|This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. Threading specific operations such as I/O, seq scans, and connection management has been discussed and will probably be implemented to enable specific performance features. Moving to a threaded engine would also require halting all other work on PostgreSQL for one to two years.}}

{{TodoItem
|"Oracle-style" optimizer hints (not wanted)
|Optimizer hints, as implemented in Oracle and other RDBMSes, are used to work around problems in the optimizer and introduce upgrade and maintenance issues. We would rather have such problems reported and fixed. We have discussed a more sophisticated system of per-class cost adjustment instead, but a specification remains to be developed. See [[OptimizerHintsDiscussion|Optimizer Hints Discussion]] for further information.}}

{{TodoItem
|Embedded server (not wanted)
|While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliably and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases. Besides, there are several very mature embedded SQL databases already available.}}

{{TodoItem
|Obfuscated function source code (not wanted)
|Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]
}}

{{TodoItem
|Indeterminate behavior for the GROUP BY clause (not wanted)
|At least one other database product allows specification of a subset of the result columns which GROUP BY would need to be able to provide predictable results; the server is free to return any value from the group. This is not viewed as a desirable feature. PostgreSQL 9.1 allows result columns that are not referenced by GROUP BY if a primary key for the same table is referenced in GROUP BY.
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]
}}

</div>

[[Category:Todo]]

91releasedraft

2011-08-26T09:13:06Z

Petere: /* Details of New Features */ fix description of collation feature

== Email Release Text ==

The PostgreSQL Global Development Group announces the release of PostgreSQL 9.1. This latest version of the leading open source database offers innovative technology, unmatched extensibility, and new features such as synchronous replication, K-Nearest Neighbor indexing, and foreign data wrappers.

“PostgreSQL 9.1 provides some of the most advanced enterprise capabilities of any open source database, and is backed by a vibrant and innovative community with proven customer success. PostgreSQL is well positioned for building and running applications in the cloud,” said Charles Fan, Sr. VP R&D, VMware.

Responding to Users

Version 9.1 delivers several features which users have been requesting for years, removing roadblocks to deploying new or ported applications on PostgreSQL. These include:

* Synchronous Replication: enable high-availability with consistency across multiple servers
* Per-Column Collations: support linguistically-correct sorting per database, table or column.
* Unlogged Tables: greatly improves performance for ephemeral data

"Heroku runs the largest PostgreSQL database-as-a-service in the world," said James Lindenbaum, Heroku co-founder. "The release of synchronous data replication with 9.1 provides our customers with innovative new ways of protecting mission-critical data, and validates PostgreSQL as one of the fastest-moving datastores available."

Advancing the State of the Art

Our community of contributors is innovating with cutting-edge features, including ones new to the entire database industry. Some of the new features that are only available on PostgreSQL:

* K-Nearest-Neighbor Indexing: index on "distance" for faster location and text-search queries
* Serializable Snapshot Isolation: keeps concurrent transactions consistent without blocking, using "true serializability"
* Writeable Common Table Expressions: execute complex multi-stage data updates in a single query
* Security-Enhanced Postgres: deploy military-grade security and Mandatory Access Control

"OpenERP has always relied on the enterprise-class features of PostgreSQL to provide a fast, reliable and scalable foundation for the Business Applications supporting our customers' operations every day. Data integrity in highly concurrent and transactional contexts is a critical topic for us, and we're very enthusiastic about the new Serializable Snapshot Isolation of PostgreSQL 9.1!" said Olivier Dony, OpenERP Community Manager.

Extending the Database Engine

PostgreSQL's extensibility enables users to add new functionality to a running production database, and use them for tasks no other database system can perform. Version 9.1 adds critical new extensibility features, including:

* Foreign Table Wrappers: attach and query other databases from PostgreSQL
* Extensions: easily create, load, and manage new database features

All of the above features, and more, are detailed on the What's New In 9.1 wiki page, as well as our release notes.

In PostgreSQL's 25th year of database development, our community continues to introduce new innovations with every annual release. Download version 9.1 now and experience the most advanced open source database system in the world.

== Extended Release ==

=== Details of New Features ===

'''Responding to Users'''

Version 9.1 delivers several features which users have been requesting for years, removing roadblocks to deploying new or ported applications on PostgreSQL. These include:

* '''Synchronous Replication for Clustering:''' Enable high-availability with consistency across multiple nodes, by deploying PostgreSQL clusters using synchronous replication. Synchronous replication supports "2-safe replication" which ensures transactions have been confirmed by a standby server in addition to the master. Synchronous replication improves reliability over other techniques, and data loss will be limited to events where both the primary and standby servers crash at the same time.

* '''Per-column Collations for Multi-lingual Databases:''' Users can now set the collation for strings on a single column. This permits true multilingual databases, where each text column is a different language, and indexes and sorts correctly for that language.

* '''Unlogged Tables to Improve Performance:''' When performance is more important than durability, unlogged tables provide a way to improve performance while keeping the data managed within PostgreSQL. Removing logging reduces I/O overhead, yielding performance improvements up to 10 times faster when compared to logged tables. Scenarios expected to leverage unlogged tables include web session data, real time logging, ETL and temporary/intermediate tables for functions.

'''Advancing the State of the Art'''

Our community is innovating, delivering cutting-edge features which are new to the database industry. Some of these features are only available on PostgreSQL.

* '''Powerful Similarity Searches with K-Nearest-Neighbor (KNN) Indexing:''' Create new applications using PostgreSQL KNN-GiST indexes, which provide innovative indexing to avoid expensive table scans. KNN enhances PostgreSQL's query capabilities by using mathematical "distance" for indexing and searches. These indexes can be used to enhance common text searches, text-similarity searches, geospatial location comparisons and other queries. Example searches that took 2 seconds without the index returned in 20 ms with this feature. Text search indexes can be also now be configured to provide indexing support for LIKE '%string%' queries without changing any SQL. PostgreSQL is among the first database systems to have KNN.

* '''Serializable Snapshot Isolation:''' allows users to enforce arbitrarily complex user-defined business rules within the database without blocking, by automatically detecting live race conditions in your SQL transactions at runtime. This feature currently exists only in PostgreSQL.

* '''Writeable Common Table Expressions (wCTE):''' Supports the relational integrity of your data by allowing you to update multiple, cascading, related records in a single statement. By using the results of one query to execute another query, you can update recursively, hierarchically, across foreign keys, or even more creatively. PostgreSQL provides the most complete and flexible implementation of this SQL feature available.

* '''Security-Enhanced Postgres (SE-Postgres):''' Deploy military-grade security and mandatory access control with full-integration support for Security-Enhanced Linux (SE-Linux). SE-Linux is a NSA project that modifies the Linux kernel with security-related functions. It has been endorsed by and included with major Linux distributions including, but not limited to, Red Hat, CentOS, Debian and Ubuntu. PostgreSQL is the only database system which has tight integration with SE-Linux.

'''Extending the Database Engine'''

PostgreSQL's extensibility enables users to add new functionality to a running production database, and use them for tasks no other database system can perform. Version 9.1 adds critical new extensibility features, including:

* Foreign Data Wrappers (FDW): as part of our standards-compliant SQL/MED support for querying data outside the PostgreSQL database, FDWs allow users to create "drivers" and attach external data sources, which can be used as read-only tables. FDWs make PostgreSQL a powerful tool for enterprise data integration, and they make migration easier. FDWs initially available from the community include comma-separated-value (CSV) files, Oracle, MySQL, CouchDB, and Twitter sources. And many more are expected in the near future.

* Extensions: while PostgreSQL has always been extensible, now users can easily create, load, upgrade, and manage any of dozens of database extensions using the EXTENSION database object. The new site PGXN.org offers a repository for contributing and downloading extensions.

=== 25th Anniversary ===

The POSTGRES project was inaugurated at the University of California, Berkeley, in June 1986 with the publication of the original POSTGRES desing by Lawrence A. Rowe and Michael R. Stonebraker. In the 25 years since then, POSTGRES became an open source project, converted to using SQL, changed its name to PostgreSQL, and became one of the leading relational databases in the world.

There have been 23 releases of POSTGRES and PostgreSQL, including version 9.1. PostgreSQL is the only major SQL database system to have consistent, featureful releases every year.

=== Full Text of Quotes ===

“PostgreSQL 9.1 provides some of the most advanced enterprise capabilities of any open source database, and is backed by a vibrant and innovative community with proven customer success. PostgreSQL is well positioned for building and running applications in the cloud,” said Charles Fan, Sr. VP R&D, VMware.

About VMWare: VMware (NYSE:VMW), the global leader in virtualization and cloud infrastructure, delivers customer-proven solutions that accelerate IT by reducing complexity and enabling more flexible, agile service delivery. VMware enables enterprises to adopt a cloud model that addresses their unique business challenges. VMware’s approach accelerates the transition to cloud computing while preserving existing investments and improving security and control. With more than 250,000 customers and 25,000 partners, VMware solutions help organizations of all sizes lower costs, increase business agility and ensure freedom of choice. Contact: prinquiries@vmware.com or phone +1 (650) 427-2485

"Heroku runs the largest PostgreSQL database-as-a-service in the world," said James Lindenbaum, Heroku co-founder. "The release of synchronous data replication with 9.1 provides our customers with innovative new ways of protecting mission-critical data, and validates PostgreSQL as one of the fastest-moving datastores available."

About Heroku: Heroku provides a platform as a service (PAAS) for building, deploying, and running cloud apps using Ruby. The architecture of our platform includes tools for deployment and management, a runtime for scalability, fault tolerance, and an add-ons system for extending the capabilities of our platform. Contact: Jill Ratkevic (jill@blackswansmedia.com)

"OpenERP has always relied on the enterprise-class features of PostgreSQL to provide a fast, reliable and scalable foundation for the Business Applications supporting our customers' operations every day. Data integrity in highly concurrent and transactional contexts is a critical topic for us, and we're very enthusiastic about the new Serializable Snapshot Isolation of PosgtreSQL 9.1! Synchronous replication and more performance optimizations are two other reasons we are looking forward to the next release of PostgreSQL, truly the epitome of Open Source software," said Olivier Dony, OpenERP Community Manager.

About OpenERP: OpenERP is an open source comprehensive suite of business applications including Sales, CRM, Project management, Warehouse management, Manufacturing, Accounting and Human Resources. OpenERP has separate client and server components. XML-RPC interfaces are available. OpenERP was founded by CEO Fabien Pinckaers in 2005. Fabien's vision was that Open Source provided a better way to meet customers' expectations. Contact: info@openerp.com

Todo

2011-08-21T07:58:58Z

Petere: /* PL/Python */ Remove obsolete items

<div style="margin: 1ex 1em; float: right;">
__TOC__
</div>

This list contains '''all known PostgreSQL bugs and feature requests'''. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].

* {{TodoPending}} - marks ordinary, incomplete items
* {{TodoEasy}} - marks items that are easier to implement
* {{TodoDone}} - marks changes that are done, and will appear in the PostgreSQL 9.2 release.

For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the mailing list.</b>

<div style="padding: 1ex 4em;">
== Administration ==

{{TodoItem
|Allow administrators to cancel multi-statement idle transactions
|This allows locks to be released, but it is complex to report the cancellation back to the client.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php <nowiki>Cancelling idle in transaction state</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00441.php <nowiki>Re: Cancelling idle in transaction state</nowiki>]
}}

{{TodoItem
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]
}}

{{TodoItem
|Set proper permissions on non-system schemas during db creation
|Currently all schemas are owned by the super-user because they are copied from the template1 database. However, since all objects are inherited from the template database, it is not clear that setting schemas to the db owner is correct.}}

{{TodoItem
|Allow log_min_messages to be specified on a per-module basis
|This would allow administrators to see more detailed information from specific sections of the backend, e.g. checkpoints, autovacuum, etc. Another idea is to allow separate configuration files for each module, or allow arbitrary SET commands to be passed to them. See also [[Logging Brainstorm]].}}

{{TodoItem
|Simplify creation of partitioned tables
|This would allow creation of partitioned tables without requiring creation of triggers or rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. See also [[Table partitioning]]
}}

{{TodoItem
|Allow custom variables to appear in pg_settings()
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]
}}

{{TodoItem
|Have custom variables be transaction-safe
* {{MessageLink|4B577E9F.8000505@dunslane.net|Custom GUCs still a bit broken}}
}}

{{TodoItem
|Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]
}}

{{TodoItem
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]
}}

{{TodoItem
|Provide a way to query the log collector subprocess to determine the name of the currently active log file
* [http://archives.postgresql.org/pgsql-general/2008-11/msg00418.php <nowiki>Current log files when rotating?</nowiki>]
}}

{{TodoItem
|Allow simpler reporting of the unix domain socket directory and allow easier configuration of its default location
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01555.php
}}

{{TodoItem
|Allow custom daemons to be automatically stopped/started along with the postmaster
|This allows easier administration of daemons like user job schedulers or replication-related daemons.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01701.php <nowiki>Re: scheduler in core</nowiki>]
}}

{{TodoItem
|Improve logging of prepared transactions recovered during startup
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>"recovering prepared transaction" after server restart message</nowiki>]
}}

{{TodoItem
|Consider using POSIX shared memory to avoid System V shared memory kernel limits
* [http://archives.postgresql.org/message-id/4DFA2673.3010009@enterprisedb.com <nowiki>POSIX shared memory patch status</nowiki>]
}}

=== Configuration files ===
{{TodoSubsection}}

{{TodoItemEasy
|Change pg_ident.conf parsing to be the same as pg_hba.conf
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg02204.php
}}

{{TodoItem
|Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00764.php
}}

{{TodoItem
|Consider normalizing fractions in postgresql.conf, perhaps using '%'
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]
}}

{{TodoItem
|Allow Kerberos to disable stripping of realms so we can check the username@realm against multiple realms
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php <nowiki>krb_match_realm patch</nowiki>]
}}

{{TodoItem
|Improve LDAP authentication configuration options
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php <nowiki>Proposed Patch - LDAPS support for servers on port 636 w/o TLS</nowiki>]
}}

{{TodoItem
|Add external tool to auto-tune some postgresql.conf parameters
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php <nowiki>Simple postgresql.conf wizard</nowiki>]
}}

{{TodoItem
|Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php <nowiki>Re: Plans for 8.4</nowiki>]
}}

{{TodoItem
|Process pg_hba.conf keywords as case-insensitive
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00432.php <nowiki>More robust pg_hba.conf parsing/error logging</nowiki>]
}}

{{TodoItem
|Create utility to compute accurate random_page_cost value
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00162.php
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00362.php
}}

{{TodoItem
|Allow configuration files to be independently validated
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php
* http://archives.postgresql.org/message-id/12666.1310774573@sss.pgh.pa.us
}}

{{TodoItem
|Allow postgresql.conf settings to be accepted by backends even if some settings are invalid for those backends
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoItem
|Allow all backends to receive postgresql.conf setting changes at the same time
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoEndSubsection}}

=== Tablespaces ===
{{TodoSubsection}}

{{TodoItem
|Allow a database in tablespace t1 with tables created in tablespace t2 to be used as a template for a new database created with default tablespace t2
|Currently all objects in the default database tablespace must have default tablespace specifications. This is because new databases are created by copying directories. If you mix default tablespace tables and tablespace-specified tables in the same directory, creating a new database from such a mixed directory would create a new database with tables that had incorrect explicit tablespaces. To fix this would require modifying pg_class in the newly copied database, which we don't currently do.}}

{{TodoItem
|Allow reporting of which objects are in which tablespaces
|This item is difficult because a tablespace can contain objects from multiple databases. There is a server-side function that returns the databases which use a specific tablespace, so this requires a tool that will call that function and connect to each database to find the objects in each database for that tablespace.}}

{{TodoItem
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original}}

{{TodoItem
|Allow per-tablespace quotas}}

{{TodoItem
|Allow tablespaces on RAM-based partitions for unlogged tables
* http://archives.postgresql.org/pgsql-advocacy/2011-05/msg00033.php
}}

{{TodoItem
|Allow toast tables to be moved to a different tablespace
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00980.php
}}

{{TodoEndSubsection}}

=== Statistics Collector ===
{{TodoSubsection}}

{{TodoItem
|Allow statistics last vacuum/analyze execution times to be displayed without requiring track_counts to be enabled
* [http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php <nowiki>row-level stats and last analyze time</nowiki>]
}}

{{TodoItem
|Clear table counters on TRUNCATE
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php <nowiki>Small TRUNCATE glitch</nowiki>]
}}

{{TodoEndSubsection}}

=== SSL ===
{{TodoSubsection}}

{{TodoItem
|Allow SSL authentication/encryption over unix domain sockets
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00924.php <nowiki>Re: Spoofing as the postmaster</nowiki>]
}}

{{TodoItem
|Allow SSL key file permission checks to be optionally disabled when sharing SSL keys with other applications
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php <nowiki>BUG #3809: SSL "unsafe" private key permissions bug</nowiki>]
}}

{{TodoItem
|Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart
|Unlike SSL CRT files, CRL (Certificate Revocation List) files are updated frequently
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00832.php <nowiki>Automatic CRL reload</nowiki>]
Alternatively or additionally supporting OCSP (online certificate security protocol) would provide real-time revocation discovery without reloading
}}

{{TodoItem
| Allow automatic selection of SSL client certificates from a certificate store
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]
}}

{{TodoItem
| Send the full certificate server chain to the client
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]
}}

{{TodoEndSubsection}}

=== Point-In-Time Recovery (PITR) ===
{{TodoSubsection}}

{{TodoItemEasy
|Create dump tool for write-ahead logs for use in determining transaction id for point-in-time recovery
|This is useful for checking PITR recovery.}}

{{TodoItem
|Allow archive_mode to be changed without server restart?
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php <nowiki>Enabling archive_mode without restart</nowiki>]
}}

{{TodoItem
|Consider avoiding WAL switching via archive_timeout if there has been no database activity
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01469.php <nowiki>archive_timeout behavior for no activity</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg00395.php <nowiki>Re: archive_timeout behavior for no activity</nowiki>]
}}

{{TodoEndSubsection}}

=== Standby server mode ===
{{TodoSubsection}}

{{TodoItem
| Allow pg_xlogfile_name() to be used in recovery mode
* [http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12@mail.gmail.com <nowiki>Streaming replication and pg_xlogfile_name()</nowiki>]
}}

{{TodoItem
| Prevent variables inherited from the server environment from begin used for making streaming replication connections.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01011.php <nowiki>Re: Parameter name standby_mode</nowiki>]
}}

{{TodoItemDone
| Allow hot file system backups on standby servers
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01727.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
}}

{{TodoItem
| Change walsender so that it applies per-role settings
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00642.php
}}

{{TodoItem
| Add more control over waiting for synchronous commit
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01611.php
}}

{{TodoItem
| Restructure configuration parameters for standby mode
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01820.php
}}

{{TodoItem
| Allow time-delayed application of logs on the standby
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00992.php
}}

{{TodoEndSubsection}}

== Data Types ==

{{TodoItem
|Fix data types where equality comparison is not intuitive, e.g. box}}

{{TodoItem
|Add support for public SYNONYMs
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php
* http://archives.postgresql.org/pgsql-general/2010-12/msg00139.php
}}

{{TodoItem
|Add support for SQL-standard GENERATED/IDENTITY columns
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]
}}

{{TodoItem
|Consider placing all sequences in a single table, or create a system view
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItem
|Consider a special data type for regular expressions
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]
}}

{{TodoItem
|Reduce BIT data type overhead using short varlena headers
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php <nowiki>storage size of "bit" data type..</nowiki>]
}}

{{TodoItem
|Allow renaming and deleting enumerated values from an existing enumerated data type
}}

{{TodoItem
|Support scoped IPv6 addresses in the inet type
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php <nowiki>strange problem with ip6</nowiki>]
}}

{{TodoItem
|Add a JSON (JavaScript Object Notation) data type
|This would behave similar to the XML data type, which is stored as text, but allows element lookup and conversion functions.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01494.php <nowiki>PATCH: Add hstore_to_json()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg00001.php <nowiki>Re: PATCH: Add hstore_to_json()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg01092.php <nowiki>Proposal: Add JSON support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00057.php <nowiki>Re: Proposal: Add JSON support</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00481.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01694.php
}}

{{TodoItem
|Considering improving performance of computing CHAR() value lengths
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00900.php <nowiki>char() overhead on read-only workloads not so insignifcant as the docs claim it is...</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01787.php <nowiki>Re: [PATCH] backend: compare word-at-a-time in bcTruelen</nowiki>]
}}

{{TodoItem
|Add overlaps geometric operators that ignore point overlaps
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00861.php
}}

=== Domains ===
{{TodoSubsection}}

{{TodoItem
|Allow functions defined as casts to domains to be called during casting
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]
}}

{{TodoItem
|Allow values to be cast to domain types
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00812.php
}}

{{TodoItem
|Make domains work better with polymorphic functions
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]
}}

{{TodoEndSubsection}}

=== Dates and Times ===
{{TodoSubsection}}

{{TodoItem
|Allow infinite intervals just like infinite timestamps}}

{{TodoItem
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules.
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]
}}

{{TodoItem
|Have timestamp subtraction not call justify_hours()?
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]
}}

{{TodoItem
|Improve TIMESTAMP WITH TIME ZONE subtraction to be DST-aware
|Currently subtracting one date from another that crosses a daylight savings time adjustment can return '1 day 1 hour', but adding that back to the first date returns a time one hour in the future. This is caused by the adjustment of '25 hours' to '1 day 1 hour', and '1 day' is the same time the next day, even if daylight savings adjustments are involved.}}

{{TodoItem
|Fix interval display to support values exceeding 2^31 hours}}

{{TodoItem
|Add overflow checking to timestamp and interval arithmetic}}

{{TodoItem
|Add function to allow the creation of timestamps using parameters
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00232.php
}}

{{TodoEndSubsection}}

=== Arrays ===
{{TodoSubsection}}

{{TodoItem
|Add support for arrays of domains
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php <nowiki>Re: updated WIP: arrays of composites</nowiki>]
}}

{{TodoItem
|Allow single-byte header storage for array elements}}

{{TodoItem
|Add function to detect if an array is empty
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php <nowiki>Re: array_length()</nowiki>]
}}

{{TodoItem
|Improve handling of empty arrays
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php <nowiki>So what's an "empty" array anyway?</nowiki>]
}}

{{TodoItem
|Improve handling of NULLs in arrays
* [http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php <nowiki>BUG #4509: array_cat's null behaviour is inconsistent</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php
}}

{{TodoEndSubsection}}

=== Binary Data ===
{{TodoSubsection}}

{{TodoItem
|Improve vacuum of large objects, like contrib/vacuumlo?}}

{{TodoItem
|Auto-delete large objects when referencing row is deleted
|contrib/lo offers this functionality.}}

{{TodoItem
|Allow read/write into TOAST values like large objects
|Writing might require the TOAST column to be stored EXTERNAL.
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00049.php
}}

{{TodoItem
|Add API for 64-bit large object access
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00781.php <nowiki>64-bit API for large objects</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01790.php
}}

{{TodoEndSubsection}}

=== MONEY Data Type ===
{{TodoSubsection}}

{{TodoItem
|Add locale-aware MONEY type, and support multiple currencies
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]
}}

{{TodoItem
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}

{{TodoEndSubsection}}

=== Text Search ===
{{TodoSubsection}}

{{TodoItem
|Allow dictionaries to change the token that is passed on to later dictionaries
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]
}}

{{TodoItem
|Consider a function-based API for '@@' searches
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Simplifying Text Search</nowiki>]
}}

{{TodoItem
|Improve text search error messages
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php <nowiki>Re: Poorly designed tsearch NOTICEs</nowiki>]
}}

{{TodoItem
|Consider changing error to warning for strings larger than one megabyte
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00062.php <nowiki>Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
}}

{{TodoItem
|tsearch and tsdicts regression tests fail in Turkish locale on glibc
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]
}}

{{TodoItem
|tsquery negator operator treated as part of lexeme
* [http://archives.postgresql.org/pgsql-bugs/2009-06/msg00346.php BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation]
}}

{{TodoItem
|Improve handling of plus signs in email address user names, and perhaps improve URL parsing
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00772.php
}}

{{TodoItem
|Improve default parser, to more easily allow adding new tokens
* http://archives.postgresql.org/message-id/23485.1297727826@sss.pgh.pa.us
}}

{{TodoItem
|Add additional support functions
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00319.php
}}

{{TodoEndSubsection}}

=== XML ===
{{TodoSubsection}}

{{TodoItem
|Allow XML arrays to be cast to other data types
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
}}

{{TodoItem
|Add XML Schema validation and xmlvalidate functions (SQL:2008)}}

{{TodoItem
|Add xmlvalidatedtd variant to support validating against a DTD?}}

{{TodoItem
|Relax-NG validation; libxml2 supports this already}}

{{TodoItem
|Allow reliable XML operation non-UTF8 server encodings (xpath(), in particular, is known to not work)
* [http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php <nowiki>BUG #4622: xpath only work in utf-8 server encoding</nowiki>]
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}

{{TodoItem
|Add functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}

{{TodoItem
|Add XMLNAMESPACES support in XMLELEMENT and elsewhere}}

{{TodoItem
|Move XSLT from contrib/xml2 to a more reasonable location
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00539.php
}}

{{TodoItem
|Report errors returned by the XSLT library
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00562.php
}}

{{TodoItem
|Improve the XSLT parameter passing API
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00416.php
}}

{{TodoItem
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}

{{TodoItem
|Add pretty-printed XML output option
|Parse a document and serialize it back in some indented form. libxml2 might support this.}}

{{TodoItem
|Add XMLQUERY (from the SQL/XML standard)}}

{{TodoItem
|Allow XML sthredding
|In some cases shredding could be better option (if there is no need to keep XML docs entirely, e.g. if we have already developed tools that understand only relational data. This would be a separate module that implements annotated schema decomposition technique, similar to DB2 and SQL Server functionality.}}

{{TodoItem
|Fix Nested or repeated xpath() that apparently mess up namespaces [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00097.php] [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00144.php] [http://archives.postgresql.org/pgsql-general/2008-03/msg00295.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/message-id/004f01c90e91$138e9d10$3aabd730$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|XPath: Adding the <x> at the root causes problems [http://archives.postgresql.org/pgsql-bugs/2008-05/msg00184.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/pgsql-general/2008-07/msg00613.php]}}

{{TodoItem
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}

{{TodoItem
|xpath_table is pretty broken anyway [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php]}}

{{TodoItem
|better handling of XPath data types [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php] [http://archives.postgresql.org/message-id/004a01c90e90$4b986d90$e2c948b0$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|Improve handling of PIs and DTDs in xmlconcat() [http://archives.postgresql.org/message-id/200904211211.n3LCB09p008988@wwwmaster.postgresql.org]}}

{{TodoItem
|Restructure XML and /contrib/xml2 functionality
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02314.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00017.php
}}

{{TodoEndSubsection}}

== Functions ==

{{TodoItem
|Allow INET subnet comparisons using non-constants to be indexed}}

{{TodoItem
|Add an INET overlaps operator, for use by exclusion constraints
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00845.php
}}

{{TodoItem
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php <nowiki>RFC for adding typmods to functions</nowiki>]
}}

{{TodoItem
|Fix IS OF so it matches the ISO specification, and add documentation
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]
}}

{{TodoItem
|Implement Boyer-Moore searching in LIKE queries
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}
}}

{{TodoItem
|Prevent malicious functions from being executed with the permissions of unsuspecting users
|Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]
}}

{{TodoItem
|Reduce memory usage of aggregates in set returning functions
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]
}}

{{TodoItem
|Fix /contrib/ltree operator
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]
}}

{{TodoItem
|Fix /contrib/btree_gist's implementation of inet indexing
* [http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php <nowiki>BUG #5705: btree_gist: Index on inet changes query result</nowiki>]
}}

{{TodoItem
|<nowiki>Fix inconsistent precedence of =, >, and < compared to <>, >=, and <=</nowiki>
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php <nowiki>BUG #3822: Nonstandard precedence for comparison operators</nowiki>]
}}

{{TodoItem
|Fix regular expression bug when using complex back-references
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php <nowiki>BUG #3645: regular expression back references seem broken</nowiki>]
}}

{{TodoItem
|Have /contrib/dblink reuse unnamed connections
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php <nowiki>dblink un-named connection doesn't get re-used</nowiki>]
}}

{{TodoItem
|Improve formatting of pg_get_viewdef() output
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01648.php <nowiki>pg_get_viewdef formattiing</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01885.php <nowiki>Re: pretty print viewdefs</nowiki>]
}}

{{TodoItem
|Add function to dump pg_depend information cleanly
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00226.php <nowiki>Elementary dependency look-up</nowiki>]
}}

{{TodoItem
|Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation
* [http://archives.postgresql.org/message-id/28488.1286461610@sss.pgh.pa.us pg_relation_size / could not open relation with OID #]
}}

=== Character Formatting ===

{{TodoSubsection}}
{{TodoItem
|Allow to_date() and to_timestamp() to accept localized month names}}

{{TodoItem
|Add missing parameter handling in to_char()
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]
}}

{{TodoItem
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]
}}

{{TodoItem
|Allow to_char() on interval values to accumulate the highest unit requested
|2= Some special format flag would be required to request such accumulation. Such functionality could also be added to EXTRACT. Prevent accumulation that crosses the month/day boundary because of the uneven number of days in a month.
* to_char(INTERVAL '1 hour 5 minutes', 'MI') => 65
* to_char(INTERVAL '43 hours 20 minutes', 'MI' ) => 2600
* to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') => 0:1:19:20
* to_char(INTERVAL '3 years 5 months','MM') => 41
}}

{{TodoItem
|Fix to_number() handling for values not matching the format string
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php <nowiki>Re: numeric_to_number() function skipping some digits</nowiki>]
}}

{{TodoEndSubsection}}

== Multi-Language Support ==

{{TodoItem
|Add NCHAR (as distinguished from ordinary varchar),}}

{{TodoItem
|Add a cares-about-collation column to pg_proc, so that unresolved-collation errors can be thrown at parse time
* [http://archives.postgresql.org/pgsql-hackers/2011-03/msg01520.php <nowiki>Open issues for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with text search configurations
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with to_char() and related functions
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Support collation-sensitive equality and hashing functions
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00472.php <nowiki> contrib/citext versus collations</nowiki>]
}}

{{TodoItem
|Add a LOCALE option to CREATE DATABASE, as a shorthand
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]
}}

{{TodoItem
|Support multiple simultaneous character sets, per SQL:2008}}

{{TodoItem
|Improve UTF8 combined character handling?}}

{{TodoItem
|Add octet_length_server() and octet_length_client()}}

{{TodoItem
|Make octet_length_client() the same as octet_length()?}}

{{TodoItem
|Fix problems with wrong runtime encoding conversion for NLS message files}}

{{TodoItem
|Add URL to more complete multi-byte regression tests
* [http://archives.postgresql.org/pgsql-hackers/2005-07/msg00272.php <nowiki>Multi-byte and client side character encoding tests for copy command..</nowiki>]
}}

{{TodoItem
|Fix contrib/fuzzystrmatch to work with multibyte encodings
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00138.php <nowiki> dmetaphone woes</nowiki>]
}}

{{TodoItem
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions
|Currently we preallocate memory based on worst-case usage.}}

{{TodoItem
|Add ability to use case-insensitive regular expressions on multi-byte characters
|Currently it works for UTF-8, but not other multi-byte encodings
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php <nowiki>Regexps vs. locale</nowiki>]
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}
}}

{{TodoItem
|Improve encoding of connection startup messages sent to the client
|Currently some authentication error messages are sent in the server encoding
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php <nowiki>encoding of PostgreSQL messages</nowiki>]
* [http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php <nowiki>Re: encoding of PostgreSQL messages</nowiki>]
}}

{{TodoItem
|More sensible support for Unicode combining characters, normal forms
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net
}}

== Views / Rules ==

{{TodoItem
|Automatically create rules on views so they are updateable, per SQL:2008
|We can only auto-create rules for simple views. For more complex cases users will still have to write rules manually.
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php <nowiki>Proposal for updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-08/msg00255.php <nowiki>Updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php <nowiki>Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle</nowiki>]
* http://wiki.postgresql.org/wiki/Updatable_views
}}

{{TodoItem
|Add the functionality of the WITH CHECK OPTION clause to CREATE VIEW}}

{{TodoItem
|Allow VIEW/RULE recompilation when the underlying tables change
|This is both difficult and controversial.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
}}

{{TodoItem
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]
}}

{{TodoItem
|Add the ability to automatically create materialized views
|Right now materialized views require the user to create triggers on the main table to keep the summary table current. SQL syntax should be able to manage the triggers and summary table automatically. A more sophisticated implementation would automatically retrieve from the summary table when the main table is referenced, if possible. See [[Materialized Views]] for implementation details
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00479.php <nowiki>GSoC - proposal - Materialized Views in PostgreSQL</nowiki>]
}}

{{TodoItem
|Improve ability to modify views via ALTER TABLE
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]
}}

{{TodoItem
|Prevent low-cost functions from seeing unauthorized view rows
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg01346.php <nowiki>Using views for row-level access control is leaky</nowiki>]
}}

== SQL Commands ==

{{TodoItem
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT}}

{{TodoItem
|Improve type determination of unknown (NULL or quoted literal) result columns for UNION/INTERSECT/EXCEPT
* [http://archives.postgresql.org/message-id/9799.1302719551@sss.pgh.pa.us <nowiki>UNION construct type cast gives poor error message</nowiki>]
}}

{{TodoItem
|Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00838.php <nowiki>WIP: grouping sets support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00466.php <nowiki>Implementation of GROUPING SETS (T431: Extended grouping capabilities)</nowiki>]
}}

{{TodoItem
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables</nowiki>]
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]
}}

{{TodoItem
|Add a GUC variable to warn about non-standard SQL usage in queries}}

{{TodoItem
|Add SQL-standard MERGE/REPLACE/UPSERT command
|MERGE is typically used to merge two tables. REPLACE or UPSERT command does UPDATE, or on failure, INSERT. See [[SQL MERGE]] for notes on the implementation details.
}}

{{TodoItem
|Add NOVICE output level for helpful messages
|For example, have it warn about unjoined tables. This could also control automatic sequence/index creation messages.
}}

{{TodoItem
|Allow NOTIFY in rules involving conditionals}}

{{TodoItem
|Allow EXPLAIN to identify tables that were skipped because of constraint_exclusion
}}

{{TodoItem
|Simplify dropping roles that have objects in several databases}}

{{TodoItem
|Allow the count returned by SELECT, etc to be represented as an int64 to allow a higher range of values}}

{{TodoItem
|Add support for WITH RECURSIVE ... CYCLE
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php <nowiki>WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows</nowiki>]}}

{{TodoItem
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}

{{TodoItem
|Allow DISTINCT to work in multiple-argument aggregate calls}}

{{TodoItem
|Add comments on system tables/columns using the information in catalogs.sgml
|Ideally the information would be pulled from the SGML file automatically.}}

{{TodoItem
|Prevent the specification of conflicting transaction read/write options
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php <nowiki>Re: SET TRANSACTION and SQL Standard</nowiki>]
}}

{{TodoItem
|Support LATERAL subqueries
|Lateral subqueries can reference columns of tables defined outside the subquery at the same level, i.e. ''laterally''.
For example, a LATERAL subquery in a FROM clause could reference tables defined in the same FROM clause.
Currently only the columns of tables defined ''above'' subqueries are recognized.
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php <nowiki>LATERAL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php <nowiki>Re: LATERAL</nowiki>]
}}

{{TodoItem
|Prevent temporary tables created with ON COMMIT DELETE ROWS from repeatedly truncating the table on every commit if the table is already empty
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00842.php
* http://archives.postgresql.org/pgsql-performance/2010-03/msg00392.php
* http://archives.postgresql.org/pgsql-performance/2010-04/msg00046.php
}}

{{TodoItem
|Allow DELETE and UPDATE to be used with LIMIT and ORDER BY
* http://archives.postgresql.org/pgadmin-hackers/2010-04/msg00078.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01997.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00021.php
}}

{{TodoItem
|Allow finer control over the caching of prepared query plans
|Currently anonymous (un-named) queries prepared via the wire protocol are replanned every time bind parameters are supplied --- allow SQL PREPARE to do the same. Also, allow control over replanning prepared queries either manually or automatically when statistics for execute parameters differ dramatically from those used during planning.
* http://archives.postgresql.org/message-id/201002151911.o1FJBYh22763@momjian.us
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00597.php
}}

{{TodoItem
|Allow PREPARE of cursors}}

{{TodoItem
|Have DISCARD PLANS discard plans cached by functions
|DISCARD all should do the same.
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00431.php
}}

{{TodoItem
|Avoid multiple-evaluation of BETWEEN and IN arguments containing volatile expressions
* http://archives.postgresql.org/message-id/4D95B605.2020709@enterprisedb.com
}}

{{TodoItem
|Fix nested CASE-WHEN constructs
* http://archives.postgresql.org/message-id/4DDCEEB8.50602@enterprisedb.com
}}

=== CREATE ===
{{TodoSubsection}}

{{TodoItem
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}

{{TodoItem
|Have WITH CONSTRAINTS also create constraint indexes
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]
}}

{{TodoItem
|Move NOT NULL constraint information to pg_constraint
|Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. Another issue is that we should probably force NOT NULL to be propagated from parent tables to children, just as CHECK constraints are. (But then does dropping PRIMARY KEY affect children?)
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg01223.php
}}

{{TodoItem
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]
}}

{{TodoItem
|Add CREATE SCHEMA ... LIKE that copies a schema}}

{{TodoItem
|Fix CREATE OR REPLACE FUNCTION to not leave objects depending on the function in inconsistent state
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]
}}

{{TodoItem
|Allow temporary tables to exist as empty by default in all sessions
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php <nowiki>idea: global temp tables</nowiki>]
* [http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php <nowiki>Re: idea: global temp tables</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg01098.php <nowiki>global temporary tables</nowiki>]
}}

{{TodoItem
|Allow the creation of "distinct" types
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php <nowiki>Distinct types</nowiki>]
}}

{{TodoItem
|Consider analyzing temporary tables when they are first used in a query
|Autovacuum cannot analyze or vacuum temporary tables.
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php <nowiki>autovacuum and temp tables support</nowiki>]
}}

{{TodoItem
|Allow an unlogged table to be changed to logged
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php
}}

{{TodoEndSubsection}}

=== UPDATE ===
{{TodoSubsection}}

{{TodoItem
|<nowiki>Allow UPDATE tab SET ROW (col, ...) = (SELECT...)</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg01308.php <nowiki>Re: [PATCHES] extension for sql update</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00865.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php <nowiki>Re: UPDATE using sub selects</nowiki>]
}}

{{TodoItem
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00016.php <nowiki>Re: Do we need a TODO? (was Re: Concurrently updating anupdatable view)</nowiki>]
}}

{{TodoItem
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows
|This is related to the previous item, which questions whether it even has the right semantics
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]
}}

{{TodoEndSubsection}}

=== ALTER ===
{{TodoSubsection}}

{{TodoItem
|Have ALTER TABLE RENAME of a SERIAL column rename the sequence
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItem
|Have ALTER SEQUENCE RENAME rename the sequence name stored in the sequence table
* [http://archives.postgresql.org/pgsql-bugs/2007-09/msg00092.php <nowiki>BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00007.php <nowiki>Re: BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItemEasy
|Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME or ALTER TABLE RENAME CONSTRAINT
* [http://archives.postgresql.org/pgsql-patches/2006-02/msg00168.php <nowiki>ALTER CONSTRAINT RENAME patch reverted</nowiki>]
}}

{{TodoItem
|Add ALTER DOMAIN to modify the underlying data type}}

{{TodoItem
|Allow ALTER TABLESPACE to move the tablespace to different directories}}

{{TodoItem
|Allow moving system tables to other tablespaces, where possible
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}

{{TodoItem
|Have ALTER INDEX update the name of a constraint using that index}}

{{TodoItem
|Allow column display reordering by recording a display, storage, and permanent id for every column?
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php <nowiki>Column reordering in pg_dump</nowiki>]
}}

{{TodoItem
|Allow deactivating (and reactivating) indexes via ALTER TABLE
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01191.php
}}

{{TodoEndSubsection}}

=== CLUSTER ===
{{TodoSubsection}}

{{TodoItem
|Automatically maintain clustering on a table
|This might require some background daemon to maintain clustering during periods of low usage. It might also require tables to be only partially filled for easier reorganization. Another idea would be to create a merged heap/index data file so an index lookup would automatically access the heap data too. A third idea would be to store heap rows in hashed groups, perhaps using a user-supplied hash function.
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]
* http://community.enterprisedb.com/git/
* [http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php <nowiki>Re: maintain_cluster_order_v5.patch</nowiki>]
}}

{{TodoEndSubsection}}

=== COPY ===
{{TodoSubsection}}

{{TodoItem
|Allow COPY to report error lines and continue
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure.
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]
}}

{{TodoItem
|Allow COPY on a newly-created table to skip WAL logging
|On crash recovery, the table involved in the COPY would be removed or have its heap and index files truncated. One issue is that no other backend should be able to add to the table at the same time, which is something that is currently allowed. This currently is done if the table is created inside the same transaction block as the COPY because no other backends can see the table.}}

{{TodoItem
|Allow COPY FROM to create index entries in bulk
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]
}}

{{TodoItem
|Allow COPY in CSV mode to control whether a quoted zero-length string is treated as NULL
|Currently this is always treated as a zero-length string, which generates an error when loading into an integer column
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php <nowiki>Re: [PATCHES] allow CSV quote in NULL</nowiki>]
}}

{{TodoItem
|Improve COPY performance
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01882.php
}}

{{TodoItem
|Allow COPY to report errors sooner
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]
}}

{{TodoItem
|Allow COPY to handle other number formats
|E.g. the German notation. Best would be something like WITH DECIMAL ','.
}}

{{TodoItem
|Allow a stalled COPY to exit if the backend is terminated
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00067.php <nowiki>Re: possible bug not in open items</nowiki>]
}}

{{TodoEndSubsection}}

=== GRANT/REVOKE ===
{{TodoSubsection}}

{{TodoItem
|Allow SERIAL sequences to inherit permissions from the base table?}}

{{TodoItem
|Allow dropping of a role that has connection rights
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php <nowiki>DROP ROLE dependency tracking ...</nowiki>]
}}
{{TodoEndSubsection}}

=== DECLARE CURSOR ===
{{TodoSubsection}}

{{TodoItem
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}

{{TodoItem
|Provide some guarantees about the behavior of cursors that invoke volatile functions
* [http://archives.postgresql.org/message-id/20997.1244563664@sss.pgh.pa.us Re: Cursor with hold emits the same row more than once across commits in 8.3.7]
}}

{{TodoEndSubsection}}

=== INSERT ===
{{TodoSubsection}}

{{TodoItem
|Allow INSERT/UPDATE of the system-generated oid value for a row}}

{{TodoItem
|In rules, allow VALUES() to contain a mixture of 'old' and 'new' references}}

{{TodoEndSubsection}}

=== SHOW/SET ===
{{TodoSubsection}}

{{TodoItem
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}

{{TodoItem
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count
* [http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php <nowiki>Re: [ADMIN] shared_buffers and shmmax</nowiki>]
}}

{{TodoEndSubsection}}

=== ANALYZE ===
{{TodoSubsection}}

{{TodoItem
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}

{{TodoItem
|Have EXPLAIN ANALYZE report rows as floating-point numbers
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg01363.php <nowiki>explain analyze rows=%.0f</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00108.php <nowiki>Re: explain analyze rows=%.0f</nowiki>]
}}

{{TodoItem
|Improve how ANALYZE computes in-doubt tuples
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]
}}

{{TodoEndSubsection}}

=== Window Functions ===
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.
{{TodoSubsection}}
{{TodoItem
|Support creation of user-defined window functions
|We have the ability to create new window functions written in C. Is it
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}

{{TodoItem
|Implement full support for window framing clauses
|In addition to done clauses described in the [http://developer.postgresql.org/pgdocs/postgres/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS latest doc], these clauses are not implemented yet.
* RANGE BETWEEN ... PRECEDING/FOLLOWING
* EXCLUDE
}}

{{TodoItem
|Investigate tuplestore performance issues
|The tuplestore_in_memory() thing is just a band-aid, we ought to try to solve it properly. tuplestore_advance seems like a weak spot as well.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php <nowiki>tuplestore potential performance problem</nowiki>]
}}

{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}

{{TodoItem
|Teach planner to evaluate multiple windows in the optimal order
|Currently windows are always evaluated in the query-specified order.
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64
}}

{{TodoItem
|Implement DISTINCT clause in window aggregates
|Some proprietary RDBMSs have implemented it already, so it helps with porting from those.}}

{{TodoEndSubsection}}

== Integrity Constraints ==
=== Keys ===

{{TodoSubsection}}

{{TodoItem
|Improve deferrable unique constraints for cases with many conflicts
|The current implementation fires a trigger for each potentially conflicting row. This might not scale well for an update that changes many key values at once.
}}

{{TodoEndSubsection}}

=== Referential Integrity ===
{{TodoSubsection}}

{{TodoItem
|Add MATCH PARTIAL referential integrity}}

{{TodoItem
|Change foreign key constraint for array -> element to mean element in array?
* [http://archives.postgresql.org/pgsql-hackers/2010-10/msg01814.php <nowiki>foreign keys for array/period contains relationships</nowiki>]
}}

{{TodoItem
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]
}}

{{TodoItem
|Optimize referential integrity checks
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php <nowiki>Can't ri_KeysEqual() consider two nulls as equal?</nowiki>]
}}

{{TodoEndSubsection}}

== Server-Side Languages ==

{{TodoItem
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}

{{TodoItem
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}

{{TodoItem
|Add more fine-grained specification of functions taking arbitrary data types
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php <nowiki>RfD: more powerful "any" types</nowiki>]
}}

{{TodoItem
|Implement stored procedures
|This might involve the control of transaction state and the return of multiple result sets
* [http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php <nowiki>PL/pgSQL stored procedure returning multiple result sets (SELECTs)?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php
* [http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php <nowiki>Gathering specs and discussion on feature (post 9.1)</nowiki>]
}}

{{TodoItem
|Allow holdable cursors in SPI}}

{{TodoItemEasy
|Add SPI_gettypmod() to return a field's typemod from a TupleDesc
* http://archives.postgresql.org/pgsql-hackers/2005-11/msg00250.php
}}

=== SQL-Language Functions ===
{{TodoSubsection}}

{{TodoItem
|Allow SQL-language functions to reference parameters by parameter name
|Currently SQL-language functions can only refer to dollar parameters, e.g. $1
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01479.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01519.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00221.php
}}

{{TodoItem
|Rethink query plan caching and timing of parse analysis within SQL-language functions
|They should work more like plpgsql functions do ...
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00078.php <nowiki>Re: BUG #6019: invalid cached plan on inherited table</nowiki>]
}}

{{TodoEndSubsection}}

=== PL/pgSQL ===
{{TodoSubsection}}

{{TodoItem
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}

{{TodoItem
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki>
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
}}

{{TodoItem
|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.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]
}}

{{TodoItem
|Consider keeping separate cached copies when search_path changes
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]
}}

{{TodoItem
|Improve handling of NULL row values vs. NULL rows
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php <nowiki>Null row vs. row of nulls in plpgsql</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01973.php
}}

{{TodoEndSubsection}}

=== PL/Perl ===
{{TodoSubsection}}

{{TodoItem
|Allow regex operations in plperl using UTF8 characters in non-UTF8 encoded databases}}

{{TodoEndSubsection}}

=== PL/Python ===
{{TodoSubsection}}

{{TodoItem
|Develop a trusted variant of PL/Python.}}

{{TodoItem
|Create a new restricted execution class that will allow passing function arguments in as locals. Passing them as globals means functions cannot be called recursively.
* [http://archives.postgresql.org/pgsql-hackers/2011-02/msg01468.php <nowiki>Re: pl/python do not delete function arguments</nowiki>]
}}

{{TodoItem
|Add a DB-API compliant interface on top of the SPI interface}}

{{TodoItem
|For functions returning a setof record with a composite type, cache the I/O functions for the composite type
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02007.php
}}

{{TodoItem
|Fix loss of information during conversion of numeric type to Python float}}

{{TodoEndSubsection}}

=== PL/Tcl ===
{{TodoSubsection}}

{{TodoItem
|Add table function support}}

{{TodoItem
|Check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, and SPI calls.}}

{{TodoEndSubsection}}

== Clients ==

{{TodoItem
|Add a function like pg_get_indexdef() that report more detailed index information
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00166.php <nowiki>BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)</nowiki>]
}}

{{TodoItem
|Split out pg_resetxlog output into pre- and post-sections
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php
}}

=== pg_ctl ===
{{TodoSubsection}}

{{TodoItem
|Allow pg_ctl to work properly with configuration files located outside the PGDATA directory
|pg_ctl can not read the pid file because it isn't located in the config directory but in the PGDATA directory. The solution is to allow pg_ctl to read and understand postgresql.conf to find the data_directory value.
* [http://archives.postgresql.org/pgsql-bugs/2009-10/msg00024.php <nowiki>BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory</nowiki>]
}}

{{TodoItem
|Modify pg_ctl behavior and exit codes to make it easier to write an LSB conforming init script
|It may be desirable to condition some of the changes on a command-line switch, to avoid breaking existing scripts. A Linux shell (sh) script is referenced which has been tested and seems to provide a high degree of conformance in multiple environments. Study of this script might suggest areas where pg_ctl could be modified to make writing an LSB conforming script easier; however, some aspects of that script would be unnecessary with other suggested changes to pg_ctl, and discussion on the lists did not reach consensus on support for all aspects of this script. Further discussion of particular changes is needed before beginning any work.
* [[Lsb_conforming_init_script|LSB conforming init script]]
These threads should be studied for other ideas on improvements:
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01390.php <nowiki>We should Axe /contrib/start-scripts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01843.php <nowiki>Linux LSB init script</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00008.php <nowiki>Re: Linux LSB init script</nowiki>]
}}

{{TodoItem
|Improve pg_ctl's detection of running postmasters
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00000.php
* http://archives.postgresql.org/pgsql-committers/2011-06/msg00001.php
}}

{{TodoEndSubsection}}

=== psql ===
{{TodoSubsection}}

{{TodoItem
|Have psql \ds show all sequences and their settings
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00916.php <nowiki>Re: TODO item: Have psql show current values for a sequence</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00401.php <nowiki>Quick patch: Display sequence owner</nowiki>]
}}

{{TodoItem
|Have \d on a sequence indicate if the sequence is owned by a table}}

{{TodoItem
|Move psql backslash database information into the backend, use mnemonic commands?
|This would allow non-psql clients to pull the same information out of the database as psql.
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]
}}

{{TodoItem
|Make psql's \d commands more consistent in their handling of schemas
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php <nowiki>Re: psql and schemas</nowiki>]
}}

{{TodoItem
|Make psql's \d commands distinguish default privileges from no privileges
|ACL displays were visibly different for the two cases before we "improved" them by using array_to_string.
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00082.php <nowiki>BUG #6021: There is no difference between default and empty access privileges with \dp</nowiki>]
}}

{{TodoItem
|Consistently display privilege information for all objects in psql}}

{{TodoItem
|Add "auto" expanded mode that outputs in expanded format if "wrapped" mode can't wrap the output to the screen width
|Consider using auto-expanded mode for backslash commands like \df+.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00417.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01638.php
}}

{{TodoItem
|Prevent tab completion of SET TRANSACTION from querying the database and therefore preventing the transaction isolation level from being set.
|Currently SET <tab> causes a database lookup to check all supported session variables. This query causes problems because setting the transaction isolation level must be the first statement of a transaction.}}

{{TodoItemEasy
|\s without arguments (display history) fails with libedit, doesn't use pager either
* [http://archives.postgresql.org/pgsql-bugs/2011-06/msg00114.php <nowiki> psql \s not working - OS X</nowiki>]
}}

{{TodoItem
|Add a \set variable to control whether \s displays line numbers
|Another option is to add \# which lists line numbers, and allows command execution.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]
}}

{{TodoItem
|Include the symbolic SQLSTATE name in verbose error reports
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]
}}

{{TodoItem
|Add prompt escape to display the client and server versions
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00310.php <nowiki>WIP patch for TODO Item: Add prompt escape to display the client and server versions</nowiki>]
}}

{{TodoItem
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.
|Currently, "wrapped" format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}

{{TodoItem
|Support the ReST table output format
|Details about the ReST format: http://docutils.sourceforge.net/rst.html#reference-documentation
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg01007.php <nowiki>Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00518.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00609.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
}}

{{TodoItem
|Add option to print advice for people familiar with other databases
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php <nowiki>MySQL-ism help patch for psql</nowiki>]
}}

{{TodoItemDone
|\dd is missing comments for several types of objects
|Comments are not handled at all for some object types, and are handled by both \dd and the individual backslash command for others. Consider a system view like pg_comments to manage this mess.
* [http://archives.postgresql.org/pgsql-general/2009-09/msg00199.php <nowiki>comment on constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php <nowiki>pg_comments</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2011-05/msg00885.php <nowiki>patch: Allow \dd to show constraint comments</nowiki>]
}}

{{TodoItem
|Add ability to edit views with \ev
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00023.php <nowiki>Adding \ev view editor?</nowiki>]
}}

{{TodoItem
|Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php
}}

{{TodoItem
|Prevent psql from sending remaining single-line multi-statement queries after reconnecting
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php
}}

{{TodoItemEasy
|Add \i option to bring in the specified file as a quoted literal
|This would be useful for creating functions and other areas. Details still need to be worked out.
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00016.php
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00020.php
}}

{{TodoItem
|Consider having psql -c read .psqlrc, for consistency
|psql -f already reads .psqlrc
}}

{{TodoItem
|Allow processing of multiple -f (file) options
}}

{{TodoItem
|Improve line drawing characters
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00386.php
}}

{{TodoEndSubsection}}

=== pg_dump / pg_restore ===
{{TodoSubsection}}

{{TodoItemEasy
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}

{{TodoItem
|Add pg_dumpall custom format dumps?
* [http://archives.postgresql.org/pgsql-general/2010-05/msg00509.php pg_dumpall custom format]
|}}

{{TodoItem
|Avoid using platform-dependent locale names in pg_dumpall output
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us
}}

{{TodoItem
|Allow selection of individual object(s) of all types, not just tables}}

{{TodoItem
|In a selective dump, allow dumping of an object and all its dependencies}}

{{TodoItem
|Add options like pg_restore -l and -L to pg_dump}}

{{TodoItem
|Add support for multiple pg_restore -t options, like pg_dump
|pg_restore's -t switch is less useful than pg_dump's in quite a few ways: no multiple switches, no pattern matching, no ability to pick up indexes and other dependent items for a selected table. It should be made to handle this switch just like pg_dump does.}}

{{TodoItem
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}

{{TodoItem
|Allow pg_dump --clean to drop roles that own objects or have privileges
|tgl says: if this is about pg_dumpall, it's done as of 8.4. If it's really about pg_dump, what does it mean? pg_dump has no business dropping roles.}}

{{TodoItem
|Remove unnecessary function pointer abstractions in pg_dump source code}}

{{TodoItem
|Allow pg_dump to utilize multiple CPUs and I/O channels by dumping multiple objects simultaneously
|The difficulty with this is getting multiple dump processes to produce a single dump output file. It also would require several sessions to share the same snapshot.
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00040.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02454.php
}}

{{TodoItem
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}

{{TodoItem
|Remove support for dumping from pre-7.3 servers
|In 7.3 and later, we can get accurate dependency information from the server. pg_dump still contains a lot of crufty code
to try to deal with the lack of dependency info in older servers, but the usefulness of maintaining that code grows small.}}

{{TodoItem
|Allow pre/data/post files when schema and data are dumped separately, for performance reasons
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00185.php <nowiki>Re: pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00821.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
}}

{{TodoItem
|Refactor handling of database attributes between pg_dump and pg_dumpall
|Currently only pg_dumpall emits database attributes, such as ALTER DATABASE SET commands and database-level GRANTs.
Many people wish that pg_dump would do that. One proposal is to let pg_dump issue such commands if the -C switch was used,
but it's unclear whether that will satisfy the demand.
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2010-05/msg00010.php summary of the issues]
}}

{{TodoItem
|Change pg_dump so that a comment on the dumped database is applied to the loaded database, even if the database has a different name.
|This will require new backend syntax, perhaps COMMENT ON CURRENT DATABASE. This is related to the previous item.}}

{{TodoItem
|Allow parallel restore of tar dumps
* [http://archives.postgresql.org/pgsql-hackers/2009-02/msg01154.php <nowiki>Re: parallel restore</nowiki>]
}}

{{TodoItem
|Allow pg_dumpall to output restorable ALTER USER/DATABASE SET settings
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00916.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00394.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02359.php
}}

{{TodoEndSubsection}}

=== ecpg ===
{{TodoSubsection}}

{{TodoItem
|Docs
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}

{{TodoItem
|Solve cardinality > 1 for input descriptors / variables?}}

{{TodoItem
|Add a semantic check level, e.g. check if a table really exists}}

{{TodoItem
|fix handling of DB attributes that are arrays}}

{{TodoItem
|Fix nested C comments}}

{{TodoItemEasy
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}

{{TodoItem
|Make SET CONNECTION thread-aware, non-standard?}}

{{TodoItem
|Allow multidimensional arrays}}

{{TodoItem
|Implement COPY FROM STDIN}}

{{TodoItem
|Provide a way to specify size of a bytea parameter
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]
}}

{{TodoItemEasy
|Fix small memory leaks in ecpg
|Memory leaks in a short running application like ecpg are not really a problem, but make debugging more complicated}}

{{TodoItem
|Allow reuse of cursor name variables
* [http://archives.postgresql.org/message-id/20100329113435.GA3430@feivel.credativ.lan <nowiki>Problems with variable cursorname in ecpg</nowiki>]
}}

{{TodoEndSubsection}}

=== libpq ===
{{TodoSubsection}}

{{TodoItem
|Prevent PQfnumber() from lowercasing unquoted column names
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}

{{TodoItem
|Allow statement results to be automatically batched to the client
|Currently all statement results are transferred to the libpq client before libpq makes the results available to the application. This feature would allow the application to make use of the first result rows while the rest are transferred, or held on the server waiting for them to be requested by libpq. One complexity is that a statement like SELECT 1/col could error out mid-way through the result set.}}

{{TodoItem
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]
}}

{{TodoItem
|Add PQexecf() that allows complex parameter substitution
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]
}}

{{TodoItem
|Add SQLSTATE and severity to errors generated within libpq itself
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01425.php
}}

{{TodoItem
|Add support for interface/ipaddress binding to libpq
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php <nowiki>SR/libpq - outbound interface/ipaddress binding</nowiki>]
}}

{{TodoEndSubsection}}

== Triggers ==

{{TodoItem
|Improve storage of deferred trigger queue
|Right now all deferred trigger information is stored in backend memory. This could exhaust memory for very large trigger queues. This item involves dumping large queues into files, or doing some kind of join to process all the triggers, some bulk operation, or a bitmap.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php <nowiki>Scaling up deferred unique checks and the after trigger queue</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00023.php
}}

{{TodoItem
|Allow triggers to be disabled in only the current session.
|This is currently possible by starting a multi-statement transaction, modifying the system tables, performing the desired SQL, restoring the system tables, and committing the transaction. ALTER TABLE ... TRIGGER requires a table lock so it is not ideal for this usage.}}

{{TodoItem
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}

{{TodoItem
|Allow statement-level triggers to access modified rows}}

{{TodoItem
|When statement-level triggers are defined on a parent table, have them fire only on the parent table, and fire child table triggers only where appropriate
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php <nowiki>Statement-level triggers and inheritance</nowiki>]
}}

{{TodoItem
|Allow AFTER triggers on system tables
|System tables are modified in many places in the backend without going through the executor and therefore not causing triggers to fire. To complete this item, the functions that modify system tables will have to fire triggers.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01665.php
* http://wiki.postgresql.org/wiki/DDL_Triggers
}}

{{TodoItem
|Tighten trigger permission checks
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]
}}

{{TodoItem
|Allow BEFORE INSERT triggers on views
* [http://archives.postgresql.org/pgsql-general/2007-02/msg01466.php <nowiki>Re: Why can't I put a BEFORE EACH ROW trigger on a view?</nowiki>]
}}

{{TodoItem
|Add database and transaction-level triggers
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]
}}

{{TodoItem
|Reduce locking requirements for creating a trigger
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php <nowiki>Re: Change lock requirements for adding a trigger</nowiki>]
}}

{{TodoItem
|Avoid requirement for "AFTER" trigger functions to return a value
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02384.php
}}

== Inheritance ==

{{TodoItem
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys
* [http://archives.postgresql.org/pgsql-hackers/2010-05/msg00285.php <nowiki>Partitioning/inherited tables vs FKs</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00039.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00305.php
}}

{{TodoItem
|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.}}

{{TodoItem
|Determine whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY). If yes, implement it.}}

{{TodoItem
|ALTER TABLE variants sometimes support recursion and sometimes not, but this is poorly/not documented, and the ONLY marker would then be silently ignored. Clarify the documentation, and reject ONLY if it is not supported.}}

== Indexes ==

{{TodoItem
|Prevent index uniqueness checks when UPDATE does not modify the column
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.
However, HOT already short-circuits this in common cases, so more work might not be helpful.}}

{{TodoItem
|Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes
|Such indexes could be more compact if there are only a few distinct values. Such indexes can also be compressed. Keeping such indexes updated can be costly.
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php <nowiki>Bitmap Indexes: request for feedback</nowiki>]
* http://archives.postgresql.org/message-id/800923.27831.qm@web29010.mail.ird.yahoo.com
}}

{{TodoItem
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02179.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00459.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02054.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01731.php
}}

{{TodoItem
|Consider having a larger statistics target for indexed columns and expression indexes.
}}

{{TodoItem
|Consider smaller indexes that record a range of values per heap page, rather than having one index entry for every heap row
|This is useful if the heap is clustered by the indexed values.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00341.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01264.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00465.php <nowiki>Grouped Index Tuples / Clustered Indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php <nowiki>Bitmapscan changes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php <nowiki>Re: GIT patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php <nowiki>Re: Index Tuple Compression Approach?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php <nowiki>Re: Index AM change proposals, redux</nowiki>]
}}

{{TodoItem
|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.
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]
}}

{{TodoItem
|Allow multiple indexes to be created concurrently, ideally via a single heap scan
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00093.php
}}

{{TodoItem
|Consider sorting entries before inserting into btree index
* [http://archives.postgresql.org/pgsql-general/2008-01/msg01010.php <nowiki>Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?</nowiki>]
}}

{{TodoItem
|Allow index scans to return matching index keys, not just the matching heap locations
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01657.php <nowiki>Re: Is this TODO item done?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01477.php <nowiki>Index-only quals</nowiki>]
}}

{{TodoItem
|Allow creation of an index that can do comparisons to test if a value is between two column values
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00757.php <nowiki>Proposal: temporal extension "period" data type</nowiki>]
}}

{{TodoItem
|Consider using "effective_io_concurrency" for index scans
* Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.
}}

=== GIST ===
{{TodoSubsection}}

{{TodoItem
|Add more GIST index support for geometric data types}}

{{TodoItem
|Allow GIST indexes to create certain complex index types, like digital trees (see Aoki)}}

{{TodoItem
|Fix performance issues in contrib/seg and contrib/cube GiST support
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00069.php <nowiki>Re: GiST index performance</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2009-06/msg00068.php <nowiki>GiST index performance</nowiki>]
}}

{{TodoEndSubsection}}

=== Hash ===
{{TodoSubsection}}

{{TodoItem
|Add UNIQUE capability to hash indexes}}

{{TodoItem
|Add hash WAL logging for crash recovery}}

{{TodoItem
|Allow multi-column hash indexes}}

{{TodoEndSubsection}}

== Sorting ==

{{TodoItem
|Consider whether duplicate keys should be sorted by block/offset
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]
}}

{{TodoItem
|Consider being smarter about memory and external files used during sorts
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php <nowiki>Re: Sorting Improvements for 8.4</nowiki>]
}}

{{TodoItem
|Consider detoasting keys before sorting}}

{{TodoItem
|Allow sorts to use more available memory
* http://archives.postgresql.org/pgsql-hackers/2007-11/msg01026.php
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01123.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg01957.php
}}

== Fsync ==

{{TodoItem
|Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether fsync does anything
|Ideally this requires a separate test program like /contrib/pg_test_fsync that can be run at initdb time or optionally later.}}

{{TodoItem
|Consider sorting writes during checkpoint
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php <nowiki>Re: Sorting writes during checkpoint</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg02012.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00278.php
}}

== Cache Usage ==

{{TodoItem
|Speed up COUNT(*)
|We could use a fixed row count and a +/- count to follow MVCC visibility rules, or a single cached value could be used and invalidated if anyone modifies the table. Another idea is to get a count directly from a unique index, but for this to be faster than a sequential scan it must avoid access to the heap to obtain tuple visibility information.
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItem
|Provide a way to calculate an "estimated COUNT(*)"
|Perhaps by using the optimizer's cardinality estimates or random sampling.
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php <nowiki>Re: Improving count(*)</nowiki>]
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItem
|Allow data to be pulled directly from indexes
|Currently indexes do not have enough tuple visibility information to allow data to be pulled from the index without also accessing the heap. The idea is to use the visibility map used for vacuum to avoid heap lookups on pages where all tuples are visible.
* [http://wiki.postgresql.org/wiki/Index-only_scans Index-Only Scans wiki]
}}

{{TodoItem
|Consider automatic caching of statements at various levels:
* Parsed query tree
* Query execute plan
* Query results

:
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]
}}

{{TodoItem
|Consider increasing internal areas (NUM_CLOG_BUFFERS) when shared buffers is increased
* [http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php <nowiki>Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php <nowiki>clog_buffers to 64 in 8.3?</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php <nowiki>CLOG Patch</nowiki>]
}}

{{TodoItem
|Consider decreasing the amount of memory used by PrivateRefCount
|
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php <nowiki>PrivateRefCount (for 8.3)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php <nowiki>Re: PrivateRefCount (for 8.3)</nowiki>]
}}

{{TodoItem
|Consider allowing higher priority queries to have referenced buffer cache pages stay in memory longer
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]
}}

== Vacuum ==

{{TodoItem
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]
}}

{{TodoItem
|Allow concurrent inserts to use recently created pages rather than creating new ones
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php
}}

{{TodoItem
|Consider having single-page pruning update the visibility map
* <nowiki>https://commitfest.postgresql.org/action/patch_view?id=75</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php <nowiki>Re: visibility maps and heap_prune</nowiki>]
}}

{{TodoItem
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]
}}

{{TodoItem
|Bias FSM towards returning free space near the beginning of the heap file, in hopes that empty pages at the end can be truncated by VACUUM
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php <nowiki>FSM search modes</nowiki>]
}}

{{TodoItem
|Consider a more compact data representation for dead tuple locations within VACUUM
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php <nowiki>Re: Have vacuum emit a warning when it runs out of maintenance_work_mem</nowiki>]
}}

{{TodoItem
|Provide more information in order to improve user-side estimates of dead space bloat in relations
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]
}}

{{TodoItem
|Improve locking behaviour of vacuum during trailing page truncation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00319.php
* http://archives.postgresql.org/message-id/4D8DF88E.7080205@Yahoo.com
}}

{{TodoItem
|Reduce the number of table scans performed by vacuum
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00605.php
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php
}}

=== Auto-vacuum ===
{{TodoSubsection}}

{{TodoItemEasy
|Issue log message to suggest VACUUM FULL if a table is nearly empty?}}

{{TodoItem
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can do that.
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]
}}

{{TodoItem
|Prevent autovacuum from running if an old transaction is still running from the last vacuum
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]
}}

{{TodoItem
|Have autoanalyze of parent tables occur when child tables are modified
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php
* http://archives.postgresql.org/pgsql-performance/2010-10/msg00271.php
}}

{{TodoEndSubsection}}

== Locking ==

{{TodoItem
|Fix priority ordering of read and write light-weight locks
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php <nowiki>lwlocks and starvation</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php <nowiki>Re: lwlocks and starvation</nowiki>]
}}

{{TodoItem
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]
}}

{{TodoItem
|Allow UPDATEs on only non-referential integrity columns not to conflict with referential integrity locks
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php <nowiki>Referential Integrity and SHARE locks</nowiki>]
}}

{{TodoItem
|Add idle_in_transaction_timeout GUC so locks are not held for long periods of time}}

{{TodoItem
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]
}}

{{TodoItem
|Detect deadlocks involving LockBufferForCleanup()
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
}}

{{TodoItem
|Allow finer control over who is cancelled in a deadlock
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01727.php
}}

{{TodoItem
|Consider a lock timeout parameter
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00485.php <nowiki>SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5</nowiki>]
}}

{{TodoItem
|Reduce number of unnecessary false positives in Serializable Snapshot Isolation
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00609.php <nowiki>SSI heap_insert and page-level predicate locks</nowiki>]
}}

== Startup Time Improvements ==

{{TodoItem
|Experiment with multi-threaded backend for backend creation
|This would prevent the overhead associated with process creation. Most operating systems have trivial process creation time compared to database startup overhead, but a few operating systems (Win32, Solaris) might benefit from threading. Also explore the idea of a single session using multiple threads to execute a statement faster.}}

{{TodoItem
|Allow backends to change their database without restart
|This allows for faster server startup.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00843.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00336.php
}}

== Write-Ahead Log ==

{{TodoItem
|Eliminate need to write full pages to WAL before page modification
|Currently, to protect against partial disk page writes, we write full page images to WAL before they are modified so we can correct any partial page writes during recovery. These pages can also be eliminated from point-in-time archive files.
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01191.php
}}

{{TodoItem
|When full page writes are off, write CRC to WAL and check file system blocks on recovery
|If CRC check fails during recovery, remember the page in case a later CRC for that page properly matches.}}

{{TodoItem
|Write full pages during file system write and not when the page is modified in the buffer cache
|This allows most full page writes to happen in the background writer. It might cause problems for applying WAL on recovery into a partially-written page, but later the full page will be replaced from WAL.}}

{{TodoItem
|Reduce WAL traffic so only modified values are written rather than entire rows
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php <nowiki>Reduction in WAL for UPDATEs</nowiki>]
}}

{{TodoItem
|Allow WAL information to recover corrupted pg_controldata
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]
}}

{{TodoItem
|Find a way to reduce rotational delay when repeatedly writing last WAL page
|Currently fsync of WAL requires the disk platter to perform a full rotation to fsync again. One idea is to write the WAL to different offsets that might reduce the rotational delay.
* [http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php <nowiki>500 tpsQL + WAL log implementation</nowiki>]
}}

{{TodoItem
|Speed WAL recovery by allowing more than one page to be prefetched
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay.
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]
}}

{{TodoItem
|Improve WAL concurrency by increasing lock granularity
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]
}}

{{TodoItem
|Be more aggressive about creating WAL files
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php <nowiki>Re: PANIC caused by open_sync on Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-07/msg01075.php <nowiki>PreallocXlogFiles</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2005-04/msg00556.php <nowiki>WAL/PITR additional items</nowiki>]
}}

{{TodoItem
|Have resource managers report the duration of their status changes
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]
}}

{{TodoItem
|Move pgfoundry's xlogdump to /contrib and have it rely more closely on the WAL backend code
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php <nowiki>xlogdump</nowiki>]
}}

{{TodoItem
|Close deleted WAL files held open in *nix by long-lived read-only backends
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]
}}

== Optimizer / Executor ==

{{TodoItem
|Improve selectivity functions for geometric operators}}

{{TodoItem
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]
}}

{{TodoItem
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG}}

{{TodoItem
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}

{{TodoItem
|Consider compressed annealing to search for query plans
|This might replace GEQO.
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us
}}

{{TodoItem
|Improve use of expression indexes for ORDER BY
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php <nowiki>Resjunk sort columns, Heikki's index-only quals patch, and bug #5000</nowiki>]
}}

{{TodoItem
|Modify the planner to better estimate caching effects
* http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php
}}

{{TodoItem
|Allow shared buffer cache contents to affect index cost computations
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php
}}

=== Hashing ===
{{TodoSubsection}}

{{TodoItem
|Consider using a hash for joining to a large IN (VALUES ...) list
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]
}}

{{TodoItem
|Allow single batch hash joins to preserve outer pathkeys
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|"lazy" hash tables - look up only the tuples that are actually requested
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid building the same hash table more than once during the same query
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid hashing for distinct and then re-hashing for hash join
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoEndSubsection}}

== Background Writer ==

{{TodoItem
|Consider having the background writer update the transaction status hint bits before writing out the page
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.}}

{{TodoItem
|Consider adding buffers the background writer finds reusable to the free list
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
}}

{{TodoItem
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
}}

{{TodoItem
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]
}}

{{TodoItem
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]
}}

== Concurrent Use of Resources ==

{{TodoItem
|Do async I/O for faster random read-ahead of data
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-09/msg00255.php <nowiki>Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-01/msg00170.php <nowiki>Bitmap index scan preread using posix_fadvise (Was: There's random access and then there's random access)</nowiki>]
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]
}}

{{TodoItem
|Experiment with multi-threaded backend for better I/O utilization
|This would allow a single query to make use of multiple I/O channels simultaneously. One idea is to create a background reader that can pre-fetch sequential and index scan pages needed by other backends. This could be expanded to allow concurrent reads from multiple devices in a partitioned table.
* http://archives.postgresql.org/pgsql-performance/2011-02/msg00123.php
}}

{{TodoItem
|Experiment with multi-threaded backend for better CPU utilization
|This would allow several CPUs to be used for a single query, such as for sorting or query execution.
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00945.php <nowiki>Multi CPU Queries - Feedback and/or suggestions wanted!</nowiki>]
}}

{{TodoItem
|SMP scalability improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

== TOAST ==

{{TodoItem
|Allow user configuration of TOAST thresholds
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]
}}

{{TodoItem
|Reduce unnecessary cases of deTOASTing
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]
}}

{{TodoItem
|Reduce costs of repeat de-TOASTing of values
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]
}}

== Monitoring ==
{{TodoItem
|Expand pg_stat_activity for easier integration with monitoring tools
|* http://archives.postgresql.org/message-id/4DFA13A5.2060200@2ndQuadrant.com
}}

{{TodoItem
|Add column to pg_stat_activity that shows the progress of long-running commands like CREATE INDEX and VACUUM
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00203.php <nowiki>EXPLAIN progress info</nowiki>]
* The CLUSTER/VACUUM FULL implementation would also be useful to track this way
}}

{{TodoItem
|Have pg_stat_activity display query strings in the correct client encoding
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php <nowiki>pg_stats queries versus per-database encodings</nowiki>]
}}

{{TodoItemEasy
|Expose pg_controldata via an SQL interface
|Helpful for monitoring replicated databases
* http://archives.postgresql.org/message-id/4B901D73.8030003@agliodbs.com
* [http://archives.postgresql.org/message-id/4B959D7A.6010907@joeconway.com initial patch]
}}

== Miscellaneous Performance ==

{{TodoItem
|Use mmap() rather than SYSV for shared buffers?
|This would remove the requirement for SYSV SHM but would introduce portability issues. Anonymous mmap (or mmap to /dev/zero) is required to prevent I/O overhead. We could also consider mmap() for writing WAL.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00750.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00756.php
}}

{{TodoItem
|Rather than consider mmap()-ing in 8k pages, consider mmap()'ing entire files into a backend?
|Doing I/O to large tables would consume a lot of address space or require frequent mapping/unmapping. Extending the file also causes mapping problems that might require mapping only individual pages, leading to thousands of mappings. Another problem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk before WAL is written.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01239.php
}}

{{TodoItem
|Consider ways of storing rows more compactly on disk:
* Reduce the row header size?
* Consider reducing on-disk varlena length from four bytes to two because a heap row cannot be more than 64k in length}}

{{TodoItem
|Consider transaction start/end performance improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php <nowiki>Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

{{TodoItem
|Allow configuration of backend priorities via the operating system
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]
}}

{{TodoItem
|Consider increasing the minimum allowed number of shared buffers
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]
}}

{{TodoItem
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]
}}

{{TodoItem
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]
}}

{{TodoItem
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]
}}

{{TodoItem
|Sort large UPDATE/DELETEs so it is done in heap order
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]
}}

{{TodoItem
|Allow one transaction to see tuples using the snapshot of another transaction
|This would assist multiple backends in working together.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php <nowiki>Transaction Snapshot Cloning</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00135.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00260.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00466.php
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00684.php
}}

{{TodoItem
|Consider decreasing the I/O caused by updating tuple hint bits
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php
}}

{{TodoItem
|Avoid the requirement of freezing pages that are infrequently modified
|If all rows on a page are visible, it is possible to set a bit in the visibility map (once the visibility map is 100% reliable) and not need to freeze the page, avoiding a page rewrite
* http://archives.postgresql.org/message-id/4BF701CF.2090205@agliodbs.com
* http://archives.postgresql.org/pgsql-hackers/2010-06/msg00082.php
}}

{{TodoItem
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]
}}

{{TodoItem
|Restructure truncation logic to be more resistant to failure
|This also involves not writing dirty buffers for a truncated or dropped relation
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php
}}

{{TodoItem
|Consider adding logic to increase large tables by more than 8k
|This would reduce file system fragmentation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00337.php
}}

== Miscellaneous Other ==

{{TodoItem
|Deal with encoding issues for filenames in the server filesystem
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}
}}

{{TodoItem
|Deal with encoding issues in the output of localeconv()
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]
}}

{{TodoItem
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg00846.php <nowiki>patch - Report the schema along table name in a referential failure error message</nowiki>]
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]
}}

{{TodoItemEasy
| Provide [http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html#LIBPQ-CONNECT-FALLBACK-APPLICATION-NAME fallback_application_name] in contrib/pgbench, oid2name, and dblink.
* {{MessageLink|w2g9837222c1004070216u3bc46b3ahbddfdffdbfb46212@mail.gmail.com|fallback_application_name and pgbench}}
}}

{{TodoItem
|Add 64-bit support to /contrib/pgbench
* http://archives.postgresql.org/pgsql-hackers/2010-07/msg00153.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00705.php
}}

== Source Code ==

{{TodoItem
|Add use of 'const' for variables in source tree}}

{{TodoItemEasy
|Remove warnings created by -Wcast-align}}

{{TodoItem
|Move platform-specific ps status display info from ps_status.c to ports}}

{{TodoItem
|Add optional CRC checksum to heap and index pages
|One difficulty is how to prevent hint bit changes from affecting the computed CRC checksum.
* http://archives.postgresql.org/message-id/19934.1226601952%40sss.pgh.pa.us
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00002.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01028.php <nowiki>double-buffering page writes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00524.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01101.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00011.php <nowiki>Re: Block-level CRC checks</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00249.php
}}

{{TodoItem
|Consider a faster CRC32 algorithm
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php
}}

{{TodoItem
|Allow cross-compiling by generating the zic database on the target system}}

{{TodoItem
|Improve NLS maintenance of libpgport messages linked onto applications}}

{{TodoItem
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}

{{TodoItem
|Allow creation of universal binaries for Darwin
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]
}}

{{TodoItem
|Consider GnuTLS if OpenSSL license becomes a problem
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]
}}

{{TodoItem
|Consider making NAMEDATALEN more configurable in future releases}}

{{TodoItem
|Research use of signals and sleep wake ups
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]
}}

{{TodoItem
|Allow C++ code to more easily access backend code
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]
}}

{{TodoItem
|Consider simplifying how memory context resets handle child contexts
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]
}}

{{TodoItem
|Create three versions of libpgport to simplify client code
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]
}}

{{TodoItem
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]
}}

{{TodoItem
|Implement the non-threaded Avahi service discovery protocol
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]
}}

{{TodoItem
|Reduce data row alignment requirements on some 64-bit systems
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]
}}

{{TodoItem
|Restructure TOAST internal storage format for greater flexibility
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]
}}

{{TodoItem
| Add regression tests for pg_dump/restore
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01967.php <nowiki>"make install-check-pg_dump" target in src/regress]</nowiki>]
}}

{{TodoItem
| Research different memory allocation methods for lists
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php
}}

=== /contrib/pg_upgrade ===
{{TodoSubsection}}

{{TodoItem
|Handle large object comments
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.
}}

{{TodoItem
|Consider using pg_depend for checking object usage in version.c
}}

{{TodoItem
|If reindex is necessary, allow it to be done in parallel with pg_dump custom format
}}

{{TodoItem
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary
|pg_class.oid is not preserved so schema.tablename must be used.
}}

{{TodoItem
|Improve testing, perhaps using the buildfarm
|The buildfarm has access to multiple versions of PostgreSQL.
}}

{{TodoItem
|Create machine-readable output of pg_controldata
|This would avoid parsing its output. The problem is we need pg_controldata output from both the old and new clusters so we would need to support both formats.
}}

{{TodoEndSubsection}}

=== Windows ===
{{TodoSubsection}}

{{TodoItem
|Remove configure.in check for link failure when cause is found}}

{{TodoItem
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}

{{TodoItem
|Allow psql to use readline once non-US code pages work with backslashes}}

{{TodoItem
|Fix problem with shared memory on the Win32 Terminal Server}}

{{TodoItem
|Improve signal handling
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]
}}

{{TodoItem
|Convert MSVC build system to remove most batch files
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]
}}

{{TodoItem
|Support pgxs when using MSVC}}

{{TodoItem
|Fix MSVC NLS support, like for to_char()
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php <nowiki>Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)</nowiki>]
}}

{{TodoItem
|Find a correct rint() substitute on Windows
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]
}}

{{TodoItem
|Fix global namespace issues when using multiple terminal server sessions
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}

{{TodoItem
|Change from the current autoconf/gmake build system to cmake
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01869.php <nowiki>About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)</nowiki>]
}}

{{TodoItem
|Improve consistency of path separator usage
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net
}}

{{TodoItem
|Fix cross-compiling on Windows
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php
}}

{{TodoItem
|Allow multiple Postgres clusters running on the same machine to distinguish themselves in the event log
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01297.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00574.php
}}

{{TodoEndSubsection}}

=== Wire Protocol Changes ===
{{TodoSubsection}}

{{TodoItem
|Allow dynamic character set handling}}

{{TodoItem
|Add decoded type, length, precision}}

{{TodoItem
|Mark result columns as known-not-null when possible
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]
}}

{{TodoItem
|Provide more control over planner treatment of statements being prepared}}

{{TodoItem
|Use compression?}}

{{TodoItem
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}

{{TodoEndSubsection}}

== Documentation ==

{{TodoItem
|Convert single quotes to apostrophes in the PDF documentation
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]
}}

{{TodoItem
|Provide a manpage for postgresql.conf
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Consider changing documentation format from SGML to XML
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]
* http://archives.postgresql.org/pgsql-docs/2011-04/msg00020.php
* http://wiki.postgresql.org/wiki/Switching_PostgreSQL_documentation_from_SGML_to_XML
}}

{{TodoItem
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com
}}

{{TodoItem
|Add diagrams to the documentation
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php
}}

== Exotic Features ==

{{TodoItem
|Add pre-parsing phase that converts non-ISO syntax to supported syntax
|This could allow SQL written for other databases to run without modification.}}

{{TodoItem
|Allow plug-in modules to emulate features from other databases}}

{{TodoItem
|Add features of Oracle-style packages
|A package would be a schema with session-local variables, public/private functions, and initialization functions. It is also possible to implement these capabilities in any schema and not use a separate "packages" syntax at all.
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]
}}

{{TodoItem
|Consider allowing control of upper/lower case folding of unquoted identifiers
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00849.php <nowiki>TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
}}

{{TodoItem
|Add autonomous transactions
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]
}}

{{TodoItem
|Give query progress indication
* [[Query progress indication]]
}}

{{TodoItem
|Rethink our type system
* [[Rethinking datatypes]]
}}

== Features We Do ''Not'' Want ==

The following features have been discussed ad nauseum on the PostgreSQL mailing lists and the consensus has been that the project is not interested in them. As such, if you are going to bring them up as potential features, you will want to be familiar with all of the arguments against these features which have been previously made over the years. If you decide to work on such features anyway, you should be aware that you face a higher-than-normal barrier to get the Project to accept them.

{{TodoItem
|All backends running as threads in a single process (not wanted)
|This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. Threading specific operations such as I/O, seq scans, and connection management has been discussed and will probably be implemented to enable specific performance features. Moving to a threaded engine would also require halting all other work on PostgreSQL for one to two years.}}

{{TodoItem
|"Oracle-style" optimizer hints (not wanted)
|Optimizer hints, as implemented in Oracle and other RDBMSes, are used to work around problems in the optimizer and introduce upgrade and maintenance issues. We would rather have such problems reported and fixed. We have discussed a more sophisticated system of per-class cost adjustment instead, but a specification remains to be developed. See [[OptimizerHintsDiscussion|Optimizer Hints Discussion]] for further information.}}

{{TodoItem
|Embedded server (not wanted)
|While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliably and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases. Besides, there are several very mature embedded SQL databases already available.}}

{{TodoItem
|Obfuscated function source code (not wanted)
|Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]
}}

{{TodoItem
|Indeterminate behavior for the GROUP BY clause (not wanted)
|At least one other database product allows specification of a subset of the result columns which GROUP BY would need to be able to provide predictable results; the server is free to return any value from the group. This is not viewed as a desirable feature. PostgreSQL 9.1 will allow result columns that are not referenced by GROUP BY if a primary key for the same table is referenced in GROUP BY.
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]
}}

</div>

[[Category:Todo]]

Todo:Collate

2011-07-11T16:23:56Z

Petere: mark page as out of date

'''Note:''' This page is out of date; what it describes has been implemented as of 2011. See [[Todo]] for future tasks.

== SQL standard COLLATE support ==

A collation is a set of rules about how a set of objects should be ordered. In general it only applies to strings because that's the only case that has any kind of debate. This is also the only case the SQL standard worries about. However, in the general case you could probably have a meaningful discussion about how geometric shapes could be ordered.

== References ==

* Charset/collate support and function parameters [http://archives.postgresql.org/pgsql-hackers/2004-10/msg01006.php]
* Proof of concept COLLATE support with patch [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00110.php]
* For review: Initial support for COLLATE [http://archives.postgresql.org/pgsql-patches/2005-09/msg00020.php]

This patch covers all the catalog changes and syntax changes required for SQL complaint COLLATE support. It also has all the necesary changes for b-tree to work with these collations. The only part missing is teaching the planner what indexes may be used for what COLLATE statement, and underlying support for multiple collations (see [[Todo:ICU]]).

This patch has severely bitrotted.

* Removing SORTFUNC_LT/REVLT [http://archives.postgresql.org/pgsql-hackers/2005-12/msg01154.php]

== Related todo items ==

[[Todo:ICU|ICU collation support]]

== Status ==

* Design submitted [http://archives.postgresql.org/pgsql-hackers/2005-12/msg01121.php] - not reviewed
* Partial Patch - abandoned

== Overview of changes required ==

* The collation is a property of a column, not of a value. At any point in a query only a single collation is current. So fields need to be added to the executor to track this.
* Functions need to know what collation their arguments are, so a field is to be added to the fmgr structure.
* Changes to grammer to allow:
** CREATE TABLE .. ( ..., field ''COLLATE <collation>'', ... )
** ALTER TABLE
** CREATE INDEX .. ON ( field ''COLLATE <collation>'' )
** CREATE INDEX .. ON ( (expr ''COLLATE <collation>'') )
** expr :: expr ''COLLATE <collation>''
** Possibly: CREATE COLLATE ..

== Discussion ==

PostgreSQL currently only supports one collation at a time, as fixed by the LC_COLLATE variable at the time the database cluster is initialised. Note that this is intrinsically broken because you can choose the encoding per database but usually collation implementations only work on a particular encoding. It's also a major problem because virtually all databases have some strings that should be considered as plain ascii strings (such as path names, urls, or even codes like 'Y' and 'N') even if they have localizable strings as well.

POSIX collation support basically consists of two functions: strxfrm() and strcoll(). The former takes a string and converts it to another string that can be passed to strcmp() to do the actual comparison. The following statement is true:

strcoll(a,b) == strcmp( strxfrm(a), strxfrm(b) )

POSIX collation only works on the current locale. This is somewhat restrictive, so most major operating systems have provided variation that work with multiple locales. This includes Win32, Linux/glibc and Mac OS X. OSes which don't include the BSDs, HPUX and Solaris.

For this reason you can actually hack multi-locale sorting in some operating systems using a pg_strxfrm() function and creating a functional index on that. [http://archives.postgresql.org/pgsql-hackers/2005-01/msg00813.php]

However, it is undesirable to have the COLLATE support depend on which platform you are running. It is possible to call setlocale() repeatedly, though the performance will be variable across platforms. It would be fine on glibc but abysmal on solaris, for example. It should be possible to defend against performance problems when only one locale is actively being used in a given query though.

Supporting [[Todo:ICU|ICU]] would give us uniform support across all platforms.

== Possible Problems ==

Fill me in...

[[Category:Todo detail|Collate]]

Switching PostgreSQL documentation from SGML to XML

2011-04-05T18:46:13Z

Petere: Created page with "For about the last 10 years, there have been occasional discussions about switching the PostgreSQL documentation from SGML to XML (whatever that might mean). Here are some point…"

Python

2011-03-18T19:09:57Z

Petere: update psycopg version support

There are several Python drivers for PostgreSQL. This is the incomplete feature matrix for them; please help complete it as you see fit.

{| border="1"
!Software
!License
!Platforms
!Python versions
!DB API 2.0
!Native (uses libpq)
!Notes
|-
|[[Psycopg]]
|LGPL
|Unix, Win32
|2.4-3.2
|yes
|yes
|Most popular libpq-based driver
|-
|[http://www.pygresql.org/ PyGreSQL]
|BSD
|Unix, Win32
|2.3-2.6
|yes
|yes
|
|-
|[http://code.google.com/p/ocpgdb/ ocpgdb]
|BSD
|Unix
|2.3-2.6
|yes
|yes
|PG8.1+
|-
|[http://python.projects.postgresql.org py-postgresql]
|BSD
|any (pure Python)
|3.0+
|yes
|no
|pure Python with optional C accelerator modules, extensive custom API
|-
|[http://barryp.org/software/bpgsql/ bpgsql ]
|LGPL
|any (pure Python)
|2.3-2.6
|yes
|no
|labeled alpha
|-
|[http://pybrary.net/pg8000/ pg8000]
|BSD
|any (pure Python)
|2.5+ / 3.0+
|yes
|no
|
|}

Obsolete/stalled:
* [http://jamwt.com/pgasync/ pgasync], no updates since 2005
* [http://sourceforge.net/projects/popy/ PoPy], no updates since 2003
* [http://pypgsql.sourceforge.net/ pyPgSQL], no updates since 2006

There is [http://wiki.python.org/moin/PostgreSQL similar page on the Python wiki]

[[Python PostgreSQL Driver TODO]]

[[Category:Python]]

PostgreSQL 9.1 Open Items

2011-01-21T15:23:09Z

Petere: added raise protocol version number

== Project Planning ==
See the [[PostgreSQL 9.1 Development Plan]].

== Issues ==
Issues to reconsider or recheck sometime later in the development cycle:

* [[standard_conforming_strings]] -- readiness of drivers and applications
* {{MessageLink|4CEA5A0F.1030602@enterprisedb.com|do latches have memory-ordering problems?}}
* {{MessageLink|201011271931.oARJVV427882@momjian.us|GIST rewrite vs. pg_upgrade}}
* Review "Long Term" list of items from [[PostgreSQL 9.0 Open Items]]
* {{MessageLink|29244.1295376372@sss.pgh.pa.us|DO blocks leak memory}}
* {{MessageLink|1293977249.5984.17.camel@vanquo.pezone.net|raise protocol version number}}

[[Category:PostgreSQL 9.1]]

Alpha release notes draft

2010-12-27T21:42:27Z

Petere: New page: The third alpha release for PostgreSQL version 9.1, 9.1alpha3, is now available. This alpha release contains several new major features added since the alpha2 release. Please download, ins...

The third alpha release for PostgreSQL version 9.1, 9.1alpha3, is now
available. This alpha release contains several new major features added
since the alpha2 release. Please download, install, and test it to give
us early feedback on the features being developed for the future
versions of PostgreSQL.

Features added in 9.1alpha3 since alpha2 include:

* KNN GiST, otherwise known as order-by-operator support for GiST, to optimize nearest-neighbor searches

* Additional instrumentation and monitoring facilities

* Several new built-in functions: format(), pg_read_binary_file(), pg_describe_object()

* New libpq functions: PQping(), PQlibVersion()

* The capability to produce crash dumps on Windows

More detail is available in the release notes:
http://developer.postgresql.org/pgdocs/postgres/release-9-1-alpha.html

These new features mean that we need you to participate in testing them.
If you are able to help with organized alpha testing, please see the
Alpha/Beta testing page: http://wiki.postgresql.org/wiki/HowToBetaTest

Alpha releases are not stable and should never be used in production;
they are for testing new features only. There is no guarantee that any
features or APIs present in the alphas will be present, or the same, in
the final release.

Alpha release information page:
http://www.postgresql.org/developer/alpha

Download the alpha release here:
http://www.postgresql.org/ftp/source/v9.1alpha3/

Alpha releases are primarily made in source code form only. Binary
packages for some operating systems will be prepared in the coming days.

PostgreSQL Release Support Policy

2010-12-16T20:21:45Z

Petere: EOL PostgreSQL 8.1

The PostgreSQL project aims to fully support a major release for '''five years''', under the terms of the [http://www.postgresql.org/support/versioning Versioning policy]

After a release falls out of full support, we may (at our committers' discretion) continue to apply further critical fixes to the source code, on a best-effort basis. No formal releases or binary packages will be produced by the project, but the updated source code will be available from our source code control system.

This policy will be followed on a best-effort basis. In extreme cases it may not be possible to support a release for the planned lifetime; for example if a serious bug is found that cannot be resolved in a given major version without significant risk to the stability of the code or loss of application compatibility. In such cases, early retirement of a major version may be required.

The first version update released after the EOL date will normally be the final one for that version. Note that this can extend support shortly past the listed date. For example, [http://www.postgresql.org/docs/7.4/static/release.html 7.4.30] and [http://www.postgresql.org/docs/8.0/static/release.html 8.0.26] were the EOL releases for those two versions. They were originally targeted for EOL as of July 2010, but those final versions were not actually released until October 2010.

=== End Of Life (EOL) dates ===

Releases which have already reached an EOL release are italicized:

{| cellspacing="0" cellpadding="5" border="1"
!Version
!EOL Date
!Release Date
|-
|''PostgreSQL 7.4''
|October 2010 (extended)
|November 2003
|-
|''PostgreSQL 8.0''
|October 2010 (extended)
|January 2005
|-
|''PostgreSQL 8.1''
|November 2010
|November 2005
|-
|PostgreSQL 8.2
|December 2011
|December 2006
|-
|PostgreSQL 8.3
|February 2013
|February 2008
|-
|PostgreSQL 8.4
|July 2014
|July 2009
|-
|PostgreSQL 9.0
|September 2015
|September 2010
|}

Note: Versions 8.1 and earlier are [http://www.postgresql.org/about/news.865 not supported] on Windows platforms.