nyuuzyou/wikis huggingface dataset:
Systemd

== Service unit configuration ==
With PostgreSQL 9.6 or newer, it is recommended to build with --with-systemd and use the unit file shown in the documentation.
With older releases, the recommended approach is to write a unit file using Type=forking and use pg_ctl for ExecStart and ExecStop.
== RemoveIPC ==
The setting
 RemoveIPC=
in logind.conf controls whether System V IPC objects are removed when a user fully logs out. System users are exempt.
This was turned on by default in systemd version 212 (2014-03-25). RHEL7 ships 219. Debian stable (jessie) ships 215. Apparently, the systemd package in RHEL7 is built with it defaulting to off.
The observed effect of this is that the semaphore objects used by a PostgreSQL server are removed at apparently random times, leading to the server crashing with log messages like
 LOG: semctl(1234567890, 0, IPC_RMID, ...) failed: Invalid argument
Shared memory segments that are still attached to are not cleaned up, so systemd will not remove shared memory segments still in use. But semaphores have no concept of a process being attached, so they will be cleaned up even if they are actually still in use.
A "user logging out" might happen as part of a maintenance job or manually when an administrator logs in as the postgres user or similar, so it is hard to prevent.
What is a "system user" is determined at systemd compile time from the SYS_UID_MAX setting in /etc/login.defs.
It is recommended to set
 RemoveIPC=no
on all server hosts used for PostgreSQL.
Also, packaging and deployment scripts should be careful to create the postgres user as a system user by using useradd -r or equivalent.
You have to do at least one of these two things, or your PostgreSQL server will be very unreliable.
See also the documentation section systemd RemoveIPC.
== KillUserProcesses ==
The setting
 KillUserProcesses=
in logind.conf controls whether all processes of a user's session should be killed when the user logs out of that session.
This was turned on by default in systemd version 230 (2016-05-21). Currently (August 2016), this is not yet shipped widely (Fedora Branched/25, Debian testing, stable-backports).
This basically means that if you start a background server process such as PostgreSQL from the shell, it will be killed when you log out, unless you take special care. This has no harmful impact on PostgreSQL server instances started through system service units. It only affects background processes started from a user shell. This could apply if you don't use systemd service units but instead orchestrate the PostgreSQL server (or any other server process) using traditional init scripts or similar scripts.
There are various ways to adjust that, including KillOnlyUsers=, KillExcludeUsers=, loginctl enable-linger, systemd-run. These are all explained on the logind.conf man page. Note that being a "system user" has no influence here.
TableStorageParameters

SELECT t.schemaname, t.relname, c.reloptions, 
 t.n_tup_upd, t.n_tup_hot_upd, 
 case when n_tup_upd > 0 
 then ((n_tup_hot_upd::numeric/n_tup_upd::numeric)*100.0)::numeric(5,2)
 else NULL
 end AS hot_ratio
FROM pg_stat_all_tables t 
 JOIN (pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid) 
 ON n.nspname = t.schemaname AND c.relname = t.relname
Thanks to Dimitri (dim) Fontaine for this handy code.
Category:SQL
Snippets
Taiwan

==PostgreSQL台灣使用者社群==
PostgreSQL台灣使用者社群官方網站
在台灣推廣PostgreSQL，為各種PostgreSQL文件進行正體中文化。
==PostgreSQL交流會==
每月均舉辦實體交流會，詳細時間地點，請加入FB社團以獲得最新社群訊息。
==線上交流==
加入我們的FB社團，分享你的觀點和疑問
* 加入社FB社團
追蹤 @pgsqlTaiwan 粉絲專頁，取得台灣社群的最新訊息
* Follow us!
==PostgreSQL正體中文使用手冊==
以正體中文台灣用語編譯，在GitBook發佈，歡迎參與協作，教學相長。
* 編譯版本為 PostgreSQL 10
* PostgreSQL 正體中文使用手冊
* 關注Github專案
==官網維運小組==
歡迎加入PostgreSQL官網維運小組，由熱血使用者們共同討論，並在Github上一起開發，幫助更多人進入PostgreSQL。
* pgsql-tw@github
* 也可以來 Facebook粉絲團看看。
* 聯絡我們：contact@postgresql.tw
==Logo==
! Category:Users group
Temporal Extensions

Postgres can be extended to become a Temporal Database.
Such databases track the history of database content over time, automatically retaining said history and allowing it to be altered and queried.
This functionality is useful when asking what the database content looked like, what the database content should have looked like to reflect actuality, or what the officially recognized facts were even though database updates had not yet been made, at any point in time.
The first 2 by themselves being uni-temporal, transaction time and valid time respectively, the first 2 together being bi-temporal, and simultaneous support for all 3 being tri-temporal.
== List of Extensions and Temporal Enhancements ==
 Temporal Extensions and Other Enhancements
Name 	Description 	Implementation	Uni-Temporal 	Bi-Temporal	Tri-Temporal	Notes
Periods 	Periods and SYSTEM VERSIONING for PostgreSQL 	Extension 	Y 	Y 	Y 	This extension recreates the behavior defined in SQL:2023 (originally in SQL:2011) around periods and tables with SYSTEM VERSIONING. It has a SQL-standard query syntax, as far as possible. Very little activity on this project, only maintenance to ensure compatibility with the latest versions.
Temporal Tables Extension	Support for temporal tables. 	Extension 	Transaction time	N 	N 	When you update or delete a row from a system-period temporal table, the old row is archived into another table, which is called the history table. New developments have been stopped for several years. There are only patches to maintain compatibility with the latest versions.
Temporal Tables 	Rewrite of Temporal Tables Extension as a trigger	Before Trigger	Transaction time	N 	N 	This rewrite aims to provide a temporal tables solution in PL/pgSQL, targeting AWS RDS, Google Cloud SQL, and Azure Database for PostgreSQL where custom C extensions aren't permitted. Development at an early age
pg_bitemporal 	Bi-Temporal Extension 	Extension 	? 	Y 	? 	Sophisticated, but the documentation consists of Chicago PUG 2020 and Chicago 2QPG (2017?) presentation videos & related slide shows. The project no longer appears to be active
== PostgreSQL Features Supporting Temporality ==
=== Types ===
* TIMESTAMP - already in PostgreSQL
* INTERVAL - already in PostgreSQL
* PERIOD
** PERIOD(DATE)
** PERIOD(TIME) and PERIOD(TIME WITH TIMEZONE)
** PERIOD(TIMESTAMP) and PERIOD(TIMESTAMP WITH TIMEZONE)
** PERIOD(INT) and PERIOD(INTEGER)
** PERIOD(SMALLINT)
** PERIOD(NUMERIC) - only with scale 0
** PERIOD(DECIMAL) - only with scale 0
Since the TIMESTAMP and INTERVAL types are in PostgreSQL, this information will focus on the PERIOD types.
=== Constructors ===
...
=== Operators ===
In the following operators, p and q are PERIODs and i is an INTERVAL.
* p = q
* p PRECEDES q
* p SUCCEEDS q
* ...
== Resources ==
 * initial RFC - contains a lot of details and further references
Category:Development
Category:Extensions
TestFest For 9 JP

== 概要 ==
PostgreSQL 9のベータリリースに合わせて、Hackathon形式で集中テストを行います。同日にサンフランシスコで行われるSFPUG_Beta_Test_Dayと連携します。
以下は現在時点での情報です。変更になる可能性がありますのでご注意ください。
Twitterハッシュタグ : #TestFest
== 内容 ==
基本的にはSFPUGのテスト内容に準じます。
* コンパイルテスト
** 各種オプション付けて
** contribモジュール
** 外部モジュール
** 回帰テスト
* pgBenchテスト
** 8.4 vs. 9.0
* 新機能テスト （新機能紹介ページ）
** ホットスタンバイ
** ストリーミングレプリケーション
** 除外制約
** LISTEN/NOTIFY
** DO文（各種言語で）
** 追加されたウィンドウ関数フレーム
** その他募集中
* データベース移行テスト データの用意もお願いします！
* アプリケーション移行テスト
** MediaWiki
** Slony
** Bucardo
** pgsnmpd
** pgpool
** textsearch_senna
** その他募集中
* ドライバ
** Java
** Python
*** psycopg2
** Perl
*** DBD::Pg
** R
** Ruby
** その他募集中
* ORMツール
** SQLAlchemy
** Django
** Hibernate
** その他募集中
9を先取りして勉強することができます。記事等観てもぱっとわからない機能も隣の人が教えてくれます。また、PostgreSQLの今後の開発や普段疑問に思っていることなどについて自由にディスカッションできます。たぶん飲みながらやるのでぐだぐだになりそうです。
== 場所 ==
フォルシア株式会社 会議室
東京都新宿区新宿4丁目3-25 オリックス新宿ビル9階
Google Map
新宿駅南口徒歩3分
東京メトロ新宿3丁目駅徒歩1分
== 時間 ==
4月4日 午前3時～午前10時（日本時間）
※サンフランシスコ時間4月3日午前11時～午後6時で行われるTestに合わせています。
時間が時間なので前日からのスタンバイあり
== 食事 ==
軽食を用意します。持ち込み（飲食）歓迎。徒歩圏内でも調達可能。
== 持ち物 ==
ラップトップ持参。インターネット環境（DHCP）は用意します。Wi-fiに対応できるかは調整中。各自テスト環境を外部サーバに用意できれば尚可。
ラップトップは若干台数貸し出し可能です。お気軽にご連絡ください。
 
準備機材
所有者 	物品 	備考
永安 	AirMac Express（無線LAN AP) 	
永安 	VAIO X 	作業用
永安 	MacBook 	テスト用or作業用
永安 	HP 2133 mini 	誰か必要な人がいれば貸し出し用
 
テスト環境
所有者 	アーキテクチャ 	OS 	IPアドレス
永安 	x86_32 (VM) 	Red Hat Enterprise Linux 5.4	（外部リモート）
永安 	x86_32 (VM) 	CentOS 5.3 	（外部リモート）
永安 	x86_32 (VM) 	FreeBSD 6.4 	（外部リモート）
永安 	x86_32 	MacOS X 10.5.8 	x.x.x.x
永安 	x86 	未定 	（Amazon EC2）
原田 	x64 	Windows 	Amazon EC2
原田 	x86,x64 	Linux(some distros) x N 	Amazon EC2
== 参加者一覧 ==
ATNDを参照ください。
http://atnd.org/events/3785
== その他 ==
* TwitterでSFPUGと連携します。
* SFPUGのUstream ( http://www.ustream.tv/channel/postgresql---sfpug ) #sfpug
* Ustream実施予定。
* Streaming Replication Q&A
* SE-PostgreSQL Q&A
* Foreign Data Wrapper Q&A
* Global Replication Test
テストの方法については、HowToBetaTestのフォーマットに従うとよいと思います。翻訳求む。
Category:PostgreSQL Events
TikiWiki CMS/Groupware

TikiWiki CMS/Groupware is a full-featured, web-based, multilingual, tightly integrated, all-in-one Wiki+CMS+Groupware, Free Source Software (GNU/LGPL), using PHP, ADOdb, Zend Framework, jQuery and Smarty. It is actively developed by a very large international community and is translated in over 35 languages. TikiWiki can be used to create all sorts of Web applications, sites, portals, knowledge base, intranets, and extranets.
A few stats to give an idea of the scope of the project
* Over 1 million lines of code.
* 220+ developers directly committing to the core, with countless other people helping with support, documentation, testing, etc.
* 1000+ pages of documentation.
* A new code commit every 2 hours (average of last 5 years)
* 16 000+ registered users on tikiwiki.org
* 700 000+ downloads
* More info: http://info.tikiwiki.org/Fact+Sheet
http://support.mozilla.com/ (10 million page views per week) is powered by Tiki
Tiki uses a database abstraction layer so it can be used with many databases (PostgreSQL, Oracle, Sybase, SQLite) in addition to MYSQL. However, support for anything but MySQL has become more & more problematic. It's not strictly a chicken & egg problem because Tiki once worked with non-MYSQL. However, without maintainers, it was lost over time.
So we have come to a difficult decision. On August 1st 2009, database independence will be dropped in Tiki unless a maintainer steps up. So Tiki will become officially MySQL-only.
Why?
--------
We would love to support many databases, especially PostgreSQL because it's an open source & community-managed project like Tiki. There are many reasons why we would want database independence and it's no use listing them here because it's not that we don't want. It's that we don't have the resources to do so. Tiki is a huge application and we would need active devs that use/maintain Tikis on other databases.
However, since we have no maintainer, we have been for a long time now in a "Worst of both worlds" situation.
*Extra code to maintain
*Bugs that never get fixed
*People that are disappointed (feeling it's "false-advertising")
*Not taking full advantage of MySQL advanced features
This is very disappointing because our community wants to be as universal as possible.
More information here:
http://dev.tikiwiki.org/Database+independence
With hopes some people in the PostgreSQL community can help.
Category:Software Ports
Timestamp Average

Here is the code to efficiently compute an average of a timestamp column. I've only tested this on 9.1, but it will probably work on earlier versions as well. Note, you'll need to cast the column to a plain timestamp (e.g. SELECT avg(tstz_col AT TIME ZONE 'UTC') FROM mytable) in order to use it with columns of type 'timestamp with time zone'. 
Author: Josh Kupershmidt
-- In order to have a reasonably efficient accumulator
-- function, we need a state variable keeping a running
-- total of seconds since the epoch, along with the number
-- of elements processed already.
CREATE TYPE ts_accum_typ AS (
 running_total numeric,
 num_elems bigint
);
-- Accumulator function. Keep a running total of the
-- number of seconds since the epoch (1970-01-01), as well
-- as the number of elements we have processed already.
CREATE OR REPLACE FUNCTION ts_accum (existing ts_accum_typ, newval timestamp)
RETURNS ts_accum_typ AS $$
DECLARE
 retval ts_accum_typ;
BEGIN
 IF newval IS NULL THEN
 RETURN existing;
 END IF;
 IF existing IS NULL THEN
 retval.running_total = EXTRACT(epoch FROM newval);
 retval.num_elems = 1;
 RETURN retval;
 ELSE
 existing.running_total = existing.running_total + EXTRACT(epoch FROM newval);
 existing.num_elems = existing.num_elems + 1;
 RETURN existing;
 END IF;
END;
$$
LANGUAGE PLPGSQL IMMUTABLE;
-- Final function for the timestamp 'avg' aggregate.
CREATE OR REPLACE FUNCTION ts_avg (existing ts_accum_typ) RETURNS timestamp AS $$
DECLARE
 since_epoch numeric;
BEGIN
 -- Handle the case when avg() is called with no rows: answer should be NULL.
 IF existing IS NULL THEN
 RETURN NULL;
 END IF;
 since_epoch = existing.running_total / existing.num_elems;
 RETURN to_timestamp(since_epoch);
END;
$$
LANGUAGE PLPGSQL IMMUTABLE;
CREATE AGGREGATE avg (timestamp)
(
	sfunc = ts_accum,
	stype = ts_accum_typ,
	finalfunc = ts_avg
);
Category:PL/pgSQL
Timestamp in another time zone relative to the current date

This page has examples for producing the timestamp value for "9AM, Yesterday, in Los Angeles".
== Timestamp with time zone, relative to the current date in the target time zone ==
 =# select now();
 now 
 -------------------------------
 2014-07-05 02:58:03.598569+02
 (1 row)
 =# select (date_trunc('day', now() AT TIME ZONE 'America/Los_Angeles' - interval '1 day') + time '09:00:00') AT TIME ZONE 'America/Los_Angeles';
 timezone 
 ------------------------
 2014-07-03 18:00:00+02
 (1 row)
== Timestamp without time zone, relative to the current date in the target time zone ==
 =# select now();
 now 
 -------------------------------
 2014-07-05 02:58:03.598569+02
 (1 row)
 =# select (date_trunc('day', now() AT TIME ZONE 'America/Los_Angeles' - interval '1 day') + time '09:00:00');
 ?column? 
 ---------------------
 2014-07-03 09:00:00
 (1 row)
Category:Timestamp_Recipes
Tips 7.x

=== Cambiar Dueño de la Base de Datos en Versiones 7.x ===
Existen algunas formas para esto. Una de ellas es utilizando una linea de comando como esta:
pg_dump -U<usuarioViejo> <base> | perl -pe 's/- <usuarioViejo>/- <usuarioNuevo>/g' > db.sql
Luego el archivo lo podés restaurar y te recomiendo borrar la base anterior del cluster.
Otra forma, que requiere más espacio (exactamente el tamaño de la base a clonar), es crear una base utilizando de template la anterior:
CREATE DATABASE pepe TEMPLATE=<viejaBase> OWNER=<nuevoDueño>;
Existe otra forma inclusive, en el caso que no contemos con espacio suficiente para los backups o para clonar la base, que consta de varios pasos (con Bash):
sudo -u postgres /usr/bin/createuser -a -d <nuevo_usuario>
sudo psql -Upostgres <base_de_datos> -c "update pg_database set datdba = (
 select usesysid from pg_shadow where usename = '<nuevo_usuario>') 
 where datname = '<base_de_datos>' ;"
Exportamos un listado de objetos (para tablas con '\d' es suficiente) de nuestra base de datos a un archivo llamado tablas.dat .Sobre ese archivo ejecutaremos:
for table in `cat tablas.dat`;do sudo psql -Upostgres <base_de_datos> -c "
 alter TABLE $table owner to <nuevo_usuario>;";done
sudo -u postgres /usr/bin/dropuser <viejo_usuario>
=== Error al leer bloques físicos ===
Suele suceder, cuando abruptamente se apaga un 'servidor', que al iniciar nos
aparezca un error PANIC: Invalid page header in block.
Existe una forma de ignorar los errores de bloque. Para esto debemos setear (con el sercicio postgresql abajo) zero_damaged_pages = on en el postgresql.conf.
Ahora teniendo esta variable seteada iniciamos postgres. Luego de haber iniciado, inmediatamente debemos generar un dump con la herramienta pg_dump.
Luego de haber finalizado esta tarea precedemos a bajar el servicio de postgres y a comentar la linea agregada en el párrafo 2.
Ahora sí podremos iniciar Postgres y restaurar la base desde el dump generado.
NOTA: zero_damaged_pages está incluido en 8.x, pero la detección de la inaccesibilidad de las páginas es automática y se repara automáticamente.
Category:Español
TOAST/ja

原文最終更新日：27 April 2015
（この情報は少なくともバージョン9.4において正確なものです）
TOASTは"ブロックサイズ"（一般的には8KB）内に1行のデータを保持しようとするPostgreSQLの仕組みです。基本的に、Postgresではデフォルトでそれぞれの最大値が8KBとなる（行が格納された）データ"ブロック"の制限が存在します。ある行がこのサイズを越えて格納される時、TOASTは基本的に大きなカラムのデータを小さな"断片"分解し、TOASTテーブルに格納します。作成したそれぞれのテーブルは、挿入する行のサイズに依存しますが、使用されるされないに関わらず、それ自身に関連した（唯一の）TOASTテーブルを持っています。これらのすべてはユーザに対し透過的であり、デフォルトで有効となっています。
基本的な初回の圧縮、または（十分ではない場合に）TOAST可能なカラムを"ラインから外す（訳注：手動でコマンド実行することで強制的にTOASTを効かせるという意味）"ことによってサイズの縮小を実現できます。ラインから外す仕組みは、大きなカラムを2KBごとに分割し、pg_toast_*テーブルにそれぞれの固まりとして格納することで実現します。データ長とカラムの内容を指し示すpg_toastへの*ポインタ*を格納するそれは普通に格納されます。ポインタシステムが実装された方法の影響で、多くのTOAST可能なカラムタイプは最大で1GBに制限されます。
一般に、最大"1GB"であるどのカラムもTOAST可能なカラムであることを意味しており、BYTEA、VARCHAR、CHARと他のもの（可変長データ"varlena"型のもの）を含みます。
デフォルトのTOASTオプションはEXTENDEDと呼ばれ、最初にカラムのデータを圧縮することを試みます。十分に圧縮されない場合は、コマンド実行により手動でTOASTテーブルへ突っ込んでください。
psqlを開き、以下のコマンド実行にて現在のTOASTオプションを表示できます。
\d+ テーブル名
例:
 => \d+ test_table_name;
 Table "name_space.test_table_name"
 Column | Type | Modifiers | Storage | Stats target | Description 
 --------+-------------------+-----------+----------+--------------+-------------
 foo | character(100000) | | extended | | 
以下のようにすることでstorageの型を変更できます。
 alter table test_blob alter column column_name set storage EXTENDED;
手動による、TOASTコマンドの発行を含まないオプションにてalterコマンドの発行する前に注意してください。何故ならコマンド発行または行サイズが8KB制限から拡張されない場合に、行挿入時に失敗を生じます（そして例外がスローされることがあります）。
一般に、行が2KB以下となるように圧縮が試され、十分に圧縮されない場合は手動でコマンド実行します。2KBに届かなくても問題なく、行の合計サイズが8KBより小さければ格納可能です。
== サイズ制限 ==
ここでの注意事項は、"ライン外"に移動されたそれぞれの行のために一つのOIDが[グローバルOIDカウンタから]生成され、そのテーブルに関連したTOASTテーブル内で追跡するために使用されます。すべてのテーブルに渡ってこれらの行が40億行を超える場合（覚えておいてください、これはグローバル共有ラッピングカウンターです）、OIDカウンタは40億行の制限近づく時に著しい速度の低下を生ずる可能性を"包括します"。http://osdir.com/ml/postgresql-pgsql-hackers/2015-01/msg01901.html を参照してください（もちろん40億行のライン外の行に対するハードリミットが存在します）。これは、TOASTで複数カラム（実際には10カラム、それぞれ大きな挿入値といったもの）を設定する場合、テーブルで制限された合計で40億行より少ない状態で納めるということも意味しています（パーティショニングは回避策となります）。
ここでの良いニュースは、もしそれぞれの行が2KBより少ない場合[特にもしそれが2KBより少ないと保証される場合]、TOASTは使用されず、40億行の制限には当たりません。同様に、行の"最も多く"が2KB制限を越えない場合、問題に奔走することはなく、もしくは修正を要求されず、テーブルごとに40億行以上のデータを持つことができます（本質的に"無制限"です）。
もし主要な型の圧縮が設定されている場合、[基本的に]圧縮を利用して行を8KB以下に圧縮することを試み、8KBいかにならない場合はラインを外すことができます。これは40億行の制限を回避する助けとなるでしょう。
別のオプションとしては、TOAST_TUPLE_THRESHOLDの"デフォルト値"を違うものにしてpostgresを再コンパイルします。
Category:Japanese
Todo

__TOC__
This list contains some known PostgreSQL bugs, some feature requests, and some things we are not even sure we want. Many of these items are hard, and some are perhaps impossible. If you would like to work on an item, please read the Developer FAQ first. There is also a development information page.
* - marks incomplete items
* - marks changes that are done, and will appear in the PostgreSQL 17 release.
Over time, it may become clear that a TODO item has become outdated or otherwise determined to be either too controversial or not worth the development effort. Such items should be retired to the Not Worth Doing page.
For help on editing this list, please see Talk:Todo. Please do not add or remove items here without discussion on the mailing list.
== Development Process ==
WARNING for Developers: Unfortunately this list does not contain all the information necessary for someone to start coding a feature. Some of these items might have become unnecessary since they were added --- others might be desirable but the implementation might be unclear. When selecting items listed below, be prepared to first discuss the value of the feature. Do not assume that you can select one, code it and then expect it to be committed. Always discuss design on Hackers list before starting to code. The flow should be:
 Desirability -> Design -> Implement -> Test -> Review -> Commit
== Administration ==
=== Tablespaces ===
=== Statistics Collector ===
=== SSL ===
=== Standby server mode ===
== Data Types ==
=== Arrays ===
=== Text Search ===
=== XML ===
* XMLDocument: https://commitfest.postgresql.org/51/5431/
* XMLCast: https://commitfest.postgresql.org/50/5110/
* XMLText: https://commitfest.postgresql.org/43/4257/
* XMLNamespaces: https://commitfest.postgresql.org/51/5456/ (for XMLElement)
== Functions ==
== Multi-Language Support ==
== Views and Rules ==
== SQL Commands ==
=== CREATE ===
=== UPDATE ===
=== ALTER ===
=== CLUSTER ===
 
=== COPY ===
=== GRANT/REVOKE ===
=== DECLARE CURSOR ===
=== SHOW/SET ===
=== ANALYZE ===
=== EXPLAIN ===
=== Window Functions ===
See .
== Integrity Constraints ==
=== Keys ===
=== Referential Integrity ===
=== Check Constraints ===
== Server-Side Languages ==
=== PL/pgSQL ===
=== PL/Python ===
== Clients ==
=== psql ===
=== pg_dump / pg_restore ===
=== pg_upgrade ===
=== ecpg ===
 
=== libpq ===
== Triggers ==
== Inheritance ==
== Indexes ==
=== GIST ===
=== Hash ===
== Sorting ==
== Cache Usage ==
== Vacuum ==
=== Auto-vacuum ===
== Locking ==
== Startup Time Improvements ==
== Write-Ahead Log ==
== Optimizer / Executor ==
=== Hashing ===
== Background Writer ==
== Concurrent Use of Resources ==
== TOAST ==
== Monitoring ==
== Miscellaneous Performance ==
== Miscellaneous Other ==
== Source Code ==
=== Windows ===
=== Wire Protocol Changes / v4 Protocol ===
== Documentation ==
== Exotic Features ==
Category:Todo
Todo:Contents

== Unofficial Todo Detail Wiki ==
This page is designed to allow people to keep detail about stuff that appears on the official TODO list, and/or stuff that would like to be. This page is this split into parts. When adding new items make sure you add them to the right part.
Developers are encouraged to include:
# A summary about what the item is
# References to the archive for email about the topic
# References to the archive for patches
# References to external entities relating to the item, for example SQL standards, competing implementations, etc.
# Updates on progress
# Links to related TODO items
=== Official TODO Detail ===
These are maintained by the project.
* Official TODO
* See the Commitfest Site for patches submitted for past, present and future consideration.
=== Unofficial TODO Detail ===
This stuff is on the TODO list, but the content is not vetted by the project.
* Collation support via ICU
* SQL Collate support
* Partitioned Tables
* XML Support
* Largeobject Enhancement
* Logging Brainstorm
* SQL/MED foreign table
* pg_restore wishlist
=== Wishlist Detail ===
If you have some pie-in-the-sky ideas not on the official TODO list, you can put them here.
* Rethinking datatypes
* Query progress indication
Category:Todo
TodoDone84

__TOC__
This list contains all PostgreSQL bugs and features requests that were solved in 8.4. There is a Todo page too for bugs and features that are still not solved.
== Administration ==
=== Configuration files ===
=== Statistics Collector ===
=== Point-In-Time Recovery (PITR) ===
== Data Types ==
=== Dates and Times ===
=== Arrays ===
== Functions ==
== Multi-Language Support ==
== Views / Rules ==
== SQL Commands ==
=== ALTER ===
=== CLUSTER ===
=== COPY ===
=== GRANT/REVOKE ===
== Server-Side Languages ==
=== PL/pgSQL ===
=== psql ===
=== pg_dump / pg_restore ===
=== ecpg ===
=== libpq ===
== Triggers ==
== Inheritance ==
== Indexes ==
=== Hash ===
== Sorting ==
== Vacuum ==
=== Auto-vacuum ===
== Miscellaneous Performance ==
== Source Code ==
=== Windows ===
Category:Todo
Category:PostgreSQL 8.4
Category:Historical information