https://wiki.postgresql.org/api.php?action=feedcontributions&user=Theory&feedformat=atomPostgreSQL wiki - User contributions [en]2024-03-28T09:16:11ZUser contributionsMediaWiki 1.35.13https://wiki.postgresql.org/index.php?title=Count_estimate&diff=38183Count estimate2023-08-24T22:22:20Z<p>Theory: Add alternate function using explain JSON formatting for cleaner parsing of output.</p>
<hr />
<div>{{SnippetInfo|count_estimate function|lang=sql}}<br />
Authors: Erwin Brandstetter, Michael Fuhr<br/><br />
Comment by: Emanuel Calvo Franco<br />
<br />
<br />
The basic SQL standard query to count the rows in a table is:<br />
<source lang="sql"><br />
SELECT count(*) FROM table_name;<br />
</source><br />
<br />
This can be rather slow because PostgreSQL has to ''check visibility for all rows'', due to the [https://www.postgresql.org/docs/current/mvcc.html MVCC model].<br />
<br />
<br />
If you don't need an ''exact'' count, the current statistic from the catalog table <code>pg_class</code> might be good enough and is ''much'' faster to retrieve for big tables.<br />
<br />
<source lang="sql"><br />
SELECT reltuples AS estimate FROM pg_class WHERE relname = 'table_name';<br />
<br />
estimate<br />
-----------<br />
100<br />
</source><br />
<br />
Tables named <code>"table_name"</code> can live in multiple schemas of a database, in which case you get multiple rows for this query. To overcome ambiguity:<br />
<br />
<source lang="sql"><br />
SELECT reltuples::bigint AS estimate FROM pg_class WHERE oid = 'schema_name.table_name'::regclass;<br />
</source><br />
<br />
The cast to <code>bigint</code> formats the <code>real</code> number nicely, especially for big counts.<br />
<br />
Quoting the [https://www.postgresql.org/docs/current/catalog-pg-class.html manual for Postgres 13 on <code>pg_class.reltuples</code>:]<br />
<br />
Number of live rows in the table. This is only an estimate used by the planner. It is updated by <code>VACUUM</code>, <code>ANALYZE</code>, and a few DDL commands such as <code>CREATE INDEX</code>.<br />
<br />
If you didn't <code>ANALYZE</code> recently (after last changes), the estimates will be off more or less.<br/><br />
If you are running the [https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM autovacuum daemon] as is the default for modern PostgreSQL, <code>ANALYZE</code> is run automatically, too (except for temporary tables which need manual attention). So the estimates should be good unless you had major changes very recently.<br />
<br />
<br />
For more sophisticated queries (other than counting ''all'' rows from a table), or if you cannot <code>SELECT</code> from the catalog table <code>pg_class</code> (which every user can by default), consider this [https://archives.postgresql.org/pgsql-sql/2005-08/msg00046.php plpgsql function by Michael Fuhr] that collects information from <code>EXPLAIN</code> output:<br />
<br />
<source lang="sql"><br />
CREATE FUNCTION count_estimate(query text)<br />
RETURNS integer<br />
LANGUAGE plpgsql AS<br />
$func$<br />
DECLARE<br />
rec record;<br />
rows integer;<br />
BEGIN<br />
FOR rec IN EXECUTE 'EXPLAIN ' || query LOOP<br />
rows := substring(rec."QUERY PLAN" FROM ' rows=([[:digit:]]+)');<br />
EXIT WHEN rows IS NOT NULL;<br />
END LOOP;<br />
<br />
RETURN rows;<br />
END<br />
$func$;<br />
</source><br />
<br />
And this updated version that takes advantage of JSON formatting added in [https://www.postgresql.org/docs/9.0/sql-explain.html Postgres 9.0]:<br />
<br />
<source lang="sql"><br />
CREATE OR REPLACE FUNCTION count_estimate(<br />
query text<br />
) RETURNS integer LANGUAGE plpgsql AS $$<br />
DECLARE<br />
plan jsonb;<br />
BEGIN<br />
EXECUTE 'EXPLAIN (FORMAT JSON)' || query INTO plan;<br />
RETURN plan->0->'Plan'->'Plan Rows';<br />
END;<br />
$$;<br />
</source><br />
<br />
<br />
Demo:<br />
<br />
<pre><br />
CREATE TEMP TABLE tbl AS SELECT * FROM generate_series(1, 1000) AS t;<br />
ANALYZE tbl;<br />
<br />
SELECT count_estimate('SELECT * FROM tbl WHERE t < 100');<br />
<br />
count_estimate <br />
----------------<br />
100<br />
<br />
EXPLAIN SELECT * FROM tbl WHERE t < 100;<br />
<br />
QUERY PLAN<br />
------------------------------------------------------<br />
Seq Scan on tbl (cost=0.00..35.00 rows=100 width=4)<br />
Filter: (t < 100)<br />
</pre><br />
<br />
As you can see, it's an ''estimate'' - actual count would be 99.<br><br />
<br />
Related web resources:<br />
* Source material: [[Why PostgreSQL Instead of MySQL: Comparing Reliability and Speed in 2007|Why PostgreSQL Instead of MySQL]] (also discusses how this is different in MySQL)<br />
* Query alternatives on Stackoverflow: [https://stackoverflow.com/a/7945274/939860 Fast way to discover the row count of a table in PostgreSQL]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PgCon2014ClusterSummit&diff=21932PgCon2014ClusterSummit2014-03-09T01:26:58Z<p>Theory: /* RSVP List */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2013 =<br />
<br />
Tuesday, May 20th<br />
<br />
2PM to 6PM<br />
<br />
Preceded by [[Pgcon2014PostgresXCmeeting|PostgresXC Meeting]] 9AM to 1PM<br />
<br />
University of Ottawa<br />
<br />
Room: TBD<br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 1:00PM to 2:00PM ====<br />
<br />
Box Lunches supplied for anyone coming for the whole day (PostgresXC + Clustering)<br />
<br />
==== 1:30PM to 2:00PM ====<br />
<br />
Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 2:00PM to 2:45PM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates (please volunteer below if you can give an update):<br />
<br />
* pgPoolII: <br />
* Postgres-XC: <br />
* Built-in Replication: <br />
* Stado:<br />
* Bucardo: <br />
* LSR & BDR:<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 16.<br />
<br />
==== 2:45PM to 3:15PM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* '''Serializable & Predicate locks on MM replication''':<br />
* '''Event Triggers''':<br />
* '''Exportable Snapshots''':<br />
* '''Planner/Parser Hooks''': <br />
* '''Logical Changeset Extraction''':<br />
<br />
==== 3:15PM to 3:45PM ====<br />
<br />
Break<br />
<br />
==== 3:45PM to 4:30PM ====<br />
<br />
Summary of Clustering API projects, continued.<br />
<br />
==== 4:30PM to 6:00PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Tatsuo Ishii (and 2 others from SRA OSS)<br />
# Mason Sharp<br />
# Bruce Momjian<br />
# Chris Browne<br />
# David Wheeler<br />
<br />
[[Category:PostgreSQL Events]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=Todo&diff=20894Todo2013-10-03T20:23:25Z<p>Theory: Add "Teach the planner how to better use partial indexes for index-only scans"</p>
<hr />
<div><div style="margin: 1ex 1em; float: right;"><br />
__TOC__<br />
</div><br />
<br />
This list contains '''known PostgreSQL bugs and feature requests''' and we hope it is complete. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].<br />
<br />
* {{TodoPending}} - marks ordinary, incomplete items<br />
* {{TodoEasy}} - marks items that are easier to implement<br />
* {{TodoDone}} - marks changes that are done, and will appear in the PostgreSQL 9.4 release.<br />
<br />
For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the mailing list.</b><br />
<br />
<b>For Developers:</b> 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:<br />
<br />
Desirability -> Design -> Implement -> Test -> Review -> Commit<br />
<br />
<div style="padding: 1ex 4em;"><br />
== Administration ==<br />
<br />
{{TodoItem<br />
|Allow administrators to cancel multi-statement idle transactions<br />
|This allows locks to be released, but it is complex to report the cancellation back to the client.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php <nowiki>Cancelling idle in transaction state</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00441.php <nowiki>Re: Cancelling idle in transaction state</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Set proper permissions on non-system schemas during db creation<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow log_min_messages to be specified on a per-module basis<br />
|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]].}}<br />
<br />
{{TodoItem<br />
|Simplify creation of partitioned tables<br />
|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]]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow custom variables to appear in pg_settings()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have custom variables be transaction-safe<br />
* {{MessageLink|4B577E9F.8000505@dunslane.net|Custom GUCs still a bit broken}}<br />
}}<br />
<br />
{{TodoItem<br />
|Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide a way to query the log collector subprocess to determine the name of the currently active log file<br />
* [http://archives.postgresql.org/pgsql-general/2008-11/msg00418.php <nowiki>Current log files when rotating?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow simpler reporting of the unix domain socket directory and allow easier configuration of its default location<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01555.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01482.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow custom daemons to be automatically stopped/started along with the postmaster<br />
|This allows easier administration of daemons like user job schedulers or replication-related daemons.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01701.php <nowiki>Re: scheduler in core</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve logging of prepared transactions recovered during startup<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>&quot;recovering prepared transaction&quot; after server restart message</nowiki>]<br />
}}<br />
<br />
=== Configuration files ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00764.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01509.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-11/msg00002.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider normalizing fractions in postgresql.conf, perhaps using '%'<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow Kerberos to disable stripping of realms so we can check the username@realm against multiple realms<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php <nowiki>krb_match_realm patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve LDAP authentication configuration options<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php <nowiki>Proposed Patch - LDAPS support for servers on port 636 w/o TLS</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add external tool to auto-tune some postgresql.conf parameters<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php <nowiki>Simple postgresql.conf wizard</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php <nowiki>Re: Plans for 8.4</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Process pg_hba.conf keywords as case-insensitive<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00432.php <nowiki>More robust pg_hba.conf parsing/error logging</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Create utility to compute accurate random_page_cost value<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00162.php<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00362.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow configuration files to be independently validated<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php<br />
* http://archives.postgresql.org/message-id/12666.1310774573@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Allow postgresql.conf settings to be accepted by backends even if some settings are invalid for those backends<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow all backends to receive postgresql.conf setting changes at the same time<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow synchronous_standby_names to be disabled after communication failure with all synchronous standby servers exceeds some timeout<br />
|This also requires successful execution of a synchronous notification command.<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00409.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Tablespaces ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|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<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow reporting of which objects are in which tablespaces<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original}}<br />
<br />
{{TodoItem<br />
|Allow per-tablespace quotas}}<br />
<br />
{{TodoItem<br />
|Allow tablespaces on RAM-based partitions for unlogged tables<br />
* http://archives.postgresql.org/pgsql-advocacy/2011-05/msg00033.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow toast tables to be moved to a different tablespace<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-05/msg00980.php]<br />
* {{messageLink|CAFEQCbH756DyyAPQ1ykh3+b+kE1-EhWRww1WO_x5v38C-uLnUg@mail.gmail.com|patch : Allow toast tables to be moved to a different tablespace}} (issues remain)<br />
* [http://archives.postgresql.org/message-id/CAFEQCbEq07OopgE5xFYv2Q3eMq45hRSJkjCBO+kvpJq9NEVhow@mail.gmail.com Allow toast tables to be moved to a different tablespace]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Statistics Collector ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow statistics last vacuum/analyze execution times to be displayed without requiring track_counts to be enabled<br />
* [http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php <nowiki>row-level stats and last analyze time</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Clear table counters on TRUNCATE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php <nowiki>Small TRUNCATE glitch</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== SSL ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow SSL authentication/encryption over unix domain sockets<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00924.php <nowiki>Re: Spoofing as the postmaster</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow SSL key file permission checks to be optionally disabled when sharing SSL keys with other applications<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php <nowiki>BUG #3809: SSL &quot;unsafe&quot; private key permissions bug</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart<br />
|Unlike SSL CRT files, CRL (Certificate Revocation List) files are updated frequently<br />
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00832.php <nowiki>Automatic CRL reload</nowiki>]<br />
Alternatively or additionally supporting OCSP (online certificate security protocol) would provide real-time revocation discovery without reloading<br />
}}<br />
<br />
{{TodoItem<br />
| Allow automatic selection of SSL client certificates from a certificate store<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Send the full certificate server chain to the client<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Point-In-Time Recovery (PITR) ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow archive_mode to be changed without server restart?<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php <nowiki>Enabling archive_mode without restart</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider avoiding WAL switching via archive_timeout if there has been no database activity<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01469.php <nowiki>archive_timeout behavior for no activity</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg00395.php <nowiki>Re: archive_timeout behavior for no activity</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow base backup from standby to continue when the standby is promoted.<br />
* [http://archives.postgresql.org/pgsql-hackers/2012-10/msg00239.php <nowiki>Re: Promoting a standby during base backup</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add recovery target option to stop as soon as consistency is reached.<br />
* [http://archives.postgresql.org/message-id/5188F87D.1080908@vmware.com <nowiki>Re: Recovery target 'immediate'</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Standby server mode ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
| Allow pg_xlogfile_name() to be used in recovery mode<br />
* [http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12@mail.gmail.com <nowiki>Streaming replication and pg_xlogfile_name()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Prevent variables inherited from the server environment from begin used for making streaming replication connections.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01011.php <nowiki>Re: Parameter name standby_mode</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Change walsender so that it applies per-role settings<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00642.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure configuration parameters for standby mode<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01820.php<br />
}}<br />
<br />
{{TodoItemf<br />
| Allow time-delayed application of logs on the standby<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00992.php<br />
}}<br />
<br />
{{TodoItem<br />
| Add -X parameter to pg_basebackup to specify a different directory for px_xlog, like initdb<br />
}}<br />
<br />
{{TodoItem<br />
| Add a new "eager" synchronous mode that starts out synchronous but reverts to asynchronous after a failure timeout period<br />
|This would require some type of command to be executed to alert administrators of this change.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg01224.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Data Types ==<br />
<br />
{{TodoItem<br />
|Fix data types where equality comparison is not intuitive, e.g. box<br />
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01643.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for public SYNONYMs<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php<br />
* http://archives.postgresql.org/pgsql-general/2010-12/msg00139.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for SQL-standard GENERATED/IDENTITY columns<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider placing all sequences in a single table, or create a system view<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2012-02/msg00258.php Removing special case OID generation]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a special data type for regular expressions<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce BIT data type overhead using short varlena headers<br />
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php <nowiki>storage size of &quot;bit&quot; data type..</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow renaming and deleting enumerated values from an existing enumerated data type<br />
}}<br />
<br />
{{TodoItem<br />
|Support scoped IPv6 addresses in the inet type<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php <nowiki>strange problem with ip6</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Considering improving performance of computing CHAR() value lengths<br />
* [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>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01787.php <nowiki>Re: [PATCH] backend: compare word-at-a-time in bcTruelen</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add overlaps geometric operators that ignore point overlaps<br />
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00861.php<br />
}}<br />
<br />
{{TodoItem<br />
|Remove or improve rounding in geometric comparison operators<br />
* http://archives.postgresql.org/message-id/9804.1346187849@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
| Add IMMUTABLE column attribute<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00623.php<br />
}}<br />
<br />
=== Domains ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow functions defined as casts to domains to be called during casting<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow values to be cast to domain types<br />
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>] <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00812.php<br />
}}<br />
<br />
{{TodoItem<br />
|Make domains work better with polymorphic functions<br />
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]<br />
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Dates and Times ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow infinite intervals just like infinite timestamps<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00076.php<br />
}}<br />
<br />
{{TodoItem<br />
|Determine how to represent date/time field extraction on infinite timestamps<br />
* [http://archives.postgresql.org/message-id/CA+mi_8bda-Fnev9iXeUbnqhVaCWzbYhHkWoxPQfBca9eDPpRMw@mail.gmail.com extract(epoch from infinity) is not 0]<br />
* [http://archives.postgresql.org/message-id/CADAkt-icuESH16uLOCXbR-dKpcvwtUJE4JWXnkdAjAAwP6j12g@mail.gmail.com converting between infinity timestamp and float8]<br />
}}<br />
<br />
<br />
{{TodoItem<br />
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC<br />
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules. <br />
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have timestamp subtraction not call justify_hours()?<br />
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve TIMESTAMP WITH TIME ZONE subtraction to be DST-aware<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Fix interval display to support values exceeding 2^31 hours}}<br />
<br />
{{TodoItem<br />
|Add overflow checking to timestamp and interval arithmetic}}<br />
<br />
{{TodoItem<br />
|Add function to allow the creation of timestamps using parameters<br />
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00232.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow a comma to denote fractional seconds in ISO-8601-compliant times (and timestamps)<br />
* http://www.postgresql.org/message-id/7D5AC9AB-238D-4FE7-8857-18D98190A4D9@justatheory.com<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Arrays ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add support for arrays of domains<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php <nowiki>Re: updated WIP: arrays of composites</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow single-byte header storage for array elements}}<br />
<br />
{{TodoItem<br />
|Add function to detect if an array is empty<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php <nowiki>Re: array_length()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of empty arrays<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php <nowiki>So what's an &quot;empty&quot; array anyway?</nowiki>]<br />
* http://archives.postgresql.org/pgsql-general/2012-07/msg00633.php<br />
* [http://www.postgresql.org/message-id/1182.1363387349@sss.pgh.pa.us <nowiki>Allow declaration of an empty array?</nowiki>]<br />
* [http://www.postgresql.org/message-id/CADxJZo0keVhSRzUnot2Y6g46tsP7f-eV28iEmBd3AtLjU-YTMA@mail.gmail.com Exorcise "zero-dimensional" arrays]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of NULLs in arrays<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php <nowiki>BUG #4509: array_cat's null behaviour is inconsistent</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Binary Data ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve vacuum of large objects, like contrib/vacuumlo?}}<br />
<br />
{{TodoItem<br />
|Auto-delete large objects when referencing row is deleted<br />
|contrib/lo offers this functionality.}}<br />
<br />
{{TodoItem<br />
|Allow read/write into TOAST values like large objects<br />
|Writing might require the TOAST column to be stored EXTERNAL.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00049.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== MONEY Data Type ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add locale-aware MONEY type, and support multiple currencies<br />
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Text Search ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow dictionaries to change the token that is passed on to later dictionaries<br />
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Exact phrase search, <br />
* [http://www.sai.msu.su/~megera/wiki/2009-08-12 <nowiki>Algebra for full-text queries</nowiki>]<br />
* [http://www.sai.msu.su/~megera/postgres/talks/2009.pdf <nowiki>Some recent advances in<br />
full-text search</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a function-based API for '@@' searches<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Some recent advances in<br />
full-text search</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve text search error messages<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php <nowiki>Re: Poorly designed tsearch NOTICEs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider changing error to warning for strings larger than one megabyte<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|tsearch and tsdicts regression tests fail in Turkish locale on glibc<br />
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]<br />
}}<br />
<br />
{{TodoItem<br />
|tsquery negator operator treated as part of lexeme<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-06/msg00346.php BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of dash and plus signs in email address user names, and perhaps improve URL parsing<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00772.php<br />
* [http://archives.postgresql.org/message-id/E1Ri8il-0008Ct-9p@wrigleys.postgresql.org tsearch does not recognize all valid emails]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve default parser, to more easily allow adding new tokens<br />
* http://archives.postgresql.org/message-id/23485.1297727826@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Add additional support functions<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00319.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== XML ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow XML arrays to be cast to other data types<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add XML Schema validation and xmlvalidate functions (SQL:2008)}}<br />
<br />
{{TodoItem<br />
|Add xmlvalidatedtd variant to support validating against a DTD?}}<br />
<br />
{{TodoItem<br />
|Relax-NG validation; libxml2 supports this already}}<br />
<br />
{{TodoItem<br />
|Allow reliable XML operation non-UTF8 server encodings (xpath(), in particular, is known to not work)<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php <nowiki>BUG #4622: xpath only work in utf-8 server encoding</nowiki>] <br />
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}<br />
<br />
{{TodoItem<br />
|Add functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}<br />
<br />
{{TodoItem<br />
|Add XMLNAMESPACES support in XMLELEMENT and elsewhere}}<br />
<br />
{{TodoItem<br />
|Move XSLT from contrib/xml2 to a more reasonable location<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00539.php<br />
}}<br />
<br />
{{TodoItem<br />
|Report errors returned by the XSLT library<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00562.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve the XSLT parameter passing API<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00416.php<br />
}}<br />
<br />
{{TodoItem<br />
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}<br />
<br />
{{TodoItem<br />
|Add pretty-printed XML output option<br />
|Parse a document and serialize it back in some indented form. libxml2 might support this.}}<br />
<br />
{{TodoItem<br />
|Add XMLQUERY (from the SQL/XML standard)}}<br />
<br />
{{TodoItem<br />
|Allow XML sthredding<br />
|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.}}<br />
<br />
{{TodoItem<br />
|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]}}<br />
<br />
{{TodoItem<br />
|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]}}<br />
<br />
{{TodoItem<br />
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}<br />
<br />
{{TodoItem<br />
|xpath_table is pretty broken anyway [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php]}}<br />
<br />
{{TodoItem<br />
|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]}}<br />
<br />
{{TodoItem<br />
|Improve handling of PIs and DTDs in xmlconcat() [http://archives.postgresql.org/message-id/200904211211.n3LCB09p008988@wwwmaster.postgresql.org]}}<br />
<br />
{{TodoItem<br />
|Restructure XML and /contrib/xml2 functionality<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02314.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00017.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Functions ==<br />
<br />
{{TodoItem<br />
|Allow INET subnet comparisons using non-constants to be indexed}}<br />
<br />
{{TodoItem<br />
|Add an INET overlaps operator, for use by exclusion constraints <br />
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00845.php<br />
}}<br />
<br />
{{TodoItem<br />
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php <nowiki>RFC for adding typmods to functions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix IS OF so it matches the ISO specification, and add documentation<br />
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement Boyer-Moore searching in LIKE queries<br />
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent malicious functions from being executed with the permissions of unsuspecting users<br />
|Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce memory usage of aggregates in set returning functions<br />
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix /contrib/ltree operator<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix /contrib/btree_gist's implementation of inet indexing<br />
* [http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php <nowiki>BUG #5705: btree_gist: Index on inet changes query result</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|<nowiki>Fix inconsistent precedence of =, &gt;, and &lt; compared to &lt;&gt;, &gt;=, and &lt;=</nowiki><br />
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php <nowiki>BUG #3822: Nonstandard precedence for comparison operators</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix regular expression bug when using complex back-references<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php <nowiki>BUG #3645: regular expression back references seem broken</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have /contrib/dblink reuse unnamed connections<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php <nowiki>dblink un-named connection doesn't get re-used</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve formatting of pg_get_viewdef() output<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01648.php <nowiki>pg_get_viewdef formattiing</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01885.php <nowiki>Re: pretty print viewdefs</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-12/msg00906.php reprise: pretty print viewdefs]<br />
}}<br />
<br />
{{TodoItem<br />
|Add function to dump pg_depend information cleanly<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00226.php <nowiki>Elementary dependency look-up</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add function to allow easier transaction id comparisons<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00786.php<br />
}}<br />
<br />
=== Character Formatting ===<br />
<br />
{{TodoSubsection}}<br />
{{TodoItem<br />
|Allow to_date() and to_timestamp() to accept localized month names}}<br />
<br />
{{TodoItem<br />
|Add missing parameter handling in to_char()<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.<br />
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow to_char() on interval values to accumulate the highest unit requested<br />
|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.<br />
* to_char(INTERVAL '1 hour 5 minutes', 'MI') =&gt; 65<br />
* to_char(INTERVAL '43 hours 20 minutes', 'MI' ) =&gt; 2600<br />
* to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') =&gt; 0:1:19:20<br />
* to_char(INTERVAL '3 years 5 months','MM') =&gt; 41<br />
}}<br />
<br />
{{TodoItem<br />
|Fix to_number() handling for values not matching the format string<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php <nowiki>Re: numeric_to_number() function skipping some digits</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Multi-Language Support ==<br />
<br />
{{TodoItem<br />
|Add NCHAR (as distinguished from ordinary varchar)<br />
* [http://www.postgresql.org/message-id/A756FAD7EDC2E24F8CAB7E2F3B5375E918B12BC0@FALEX03.au.fjanz.com UTF8 national character data type support WIP patch and list of open issues.]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a cares-about-collation column to pg_proc, so that unresolved-collation errors can be thrown at parse time<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-03/msg01520.php <nowiki>Open issues for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Integrate collations with text search configurations<br />
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Integrate collations with to_char() and related functions<br />
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support collation-sensitive equality and hashing functions<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00472.php <nowiki> contrib/citext versus collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a LOCALE option to CREATE DATABASE, as a shorthand<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support multiple simultaneous character sets, per SQL:2008}}<br />
<br />
{{TodoItem<br />
|Improve UTF8 combined character handling?}}<br />
<br />
{{TodoItem<br />
|Add octet_length_server() and octet_length_client()}}<br />
<br />
{{TodoItem<br />
|Make octet_length_client() the same as octet_length()?}}<br />
<br />
{{TodoItem<br />
|Fix problems with wrong runtime encoding conversion for NLS message files}}<br />
<br />
{{TodoItem<br />
|Add URL to more complete multi-byte regression tests<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-07/msg00272.php <nowiki>Multi-byte and client side character encoding tests for copy command..</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix contrib/fuzzystrmatch to work with multibyte encodings<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00138.php <nowiki> dmetaphone woes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions<br />
|Currently we preallocate memory based on worst-case usage.}}<br />
<br />
{{TodoItem<br />
|Add ability to use case-insensitive regular expressions on multi-byte characters<br />
|Currently it works for UTF-8, but not other multi-byte encodings<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php <nowiki>Regexps vs. locale</nowiki>]<br />
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}<br />
}}<br />
<br />
{{TodoItem<br />
|Improve encoding of connection startup messages sent to the client<br />
|Currently some authentication error messages are sent in the server encoding<br />
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php <nowiki>encoding of PostgreSQL messages</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php <nowiki>Re: encoding of PostgreSQL messages</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|More sensible support for Unicode combining characters, normal forms<br />
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net<br />
}}<br />
<br />
== Views and Rules ==<br />
<br />
{{TodoItemDone<br />
|Add the functionality of the WITH CHECK OPTION clause to CREATE VIEW<br />
}}<br />
{{TodoItem<br />
|Allow VIEW/RULE recompilation when the underlying tables change<br />
|This is both difficult and controversial.<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change2"]<br />
* [http://archives.postgresql.org/message-id/CACk%3DU9NFSzWrEba8G5dZ%3DTZLy3_hx3QXGyCcKVWT%3D4iA1FjMuA@mail.gmail.com VIEW still referring to old name of field]<br />
}}<br />
{{TodoItem<br />
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve ability to modify views via ALTER TABLE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]<br />
}}<br />
<br />
== SQL Commands ==<br />
<br />
{{TodoItem<br />
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT<br />
* [http://dissipatedheat.com/2011/11/10/how-not-to-write-a-patch-for-postgresql/ How not to write this patch.]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve type determination of unknown (NULL or quoted literal) result columns for UNION/INTERSECT/EXCEPT<br />
* [http://archives.postgresql.org/message-id/9799.1302719551@sss.pgh.pa.us <nowiki>UNION construct type cast gives poor error message</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00838.php <nowiki>WIP: grouping sets support</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00466.php <nowiki>Implementation of GROUPING SETS (T431: Extended grouping capabilities)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: &quot;could not open relation 1663/16384/16584: No such file or directory&quot; in a specific combination of transactions with temp tables</nowiki>]<br />
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a GUC variable to warn about non-standard SQL usage in queries}}<br />
<br />
{{TodoItem<br />
|Add SQL-standard MERGE/REPLACE/UPSERT command<br />
|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.<br />
}}<br />
<br />
{{TodoItem<br />
|Add NOVICE output level for helpful messages<br />
|For example, have it warn about unjoined tables. This could also control automatic sequence/index creation messages.<br />
}}<br />
<br />
{{TodoItem<br />
|Allow NOTIFY in rules involving conditionals}}<br />
<br />
{{TodoItem<br />
|Allow EXPLAIN to identify tables that were skipped because of constraint_exclusion<br />
}}<br />
<br />
{{TodoItem<br />
|Simplify dropping roles that have objects in several databases}}<br />
<br />
{{TodoItem<br />
|Allow the count returned by SELECT, etc to be represented as an int64 to allow a higher range of values}}<br />
<br />
{{TodoItem<br />
|Add support for WITH RECURSIVE ... CYCLE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php <nowiki>WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows</nowiki>]}}<br />
<br />
{{TodoItem<br />
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner<br />
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}<br />
<br />
{{TodoItem<br />
|Allow DISTINCT to work in multiple-argument aggregate calls}}<br />
<br />
{{TodoItem<br />
|Add comments on system tables/columns using the information in catalogs.sgml<br />
|Ideally the information would be pulled from the SGML file automatically.}}<br />
<br />
{{TodoItem<br />
|Prevent the specification of conflicting transaction read/write options<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php <nowiki>Re: SET TRANSACTION and SQL Standard</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow DELETE and UPDATE to be used with LIMIT and ORDER BY<br />
* http://archives.postgresql.org/pgadmin-hackers/2010-04/msg00078.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01997.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00021.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow PREPARE of cursors}}<br />
<br />
{{TodoItem<br />
|Have DISCARD PLANS discard plans cached by functions<br />
|DISCARD all should do the same.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00431.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid multiple-evaluation of BETWEEN and IN arguments containing volatile expressions<br />
* http://archives.postgresql.org/message-id/4D95B605.2020709@enterprisedb.com<br />
}}<br />
<br />
{{TodoItem<br />
|Fix nested CASE-WHEN constructs<br />
* http://archives.postgresql.org/message-id/4DDCEEB8.50602@enterprisedb.com<br />
}}<br />
<br />
{{TodoItem<br />
|IS NULL testing of nested ROW() values is inconsistent<br />
* http://www.postgresql.org/message-id/50B3D11F.20408@2ndQuadrant.com<br />
}}<br />
<br />
=== CREATE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}<br />
<br />
{{TodoItem<br />
|Have WITH CONSTRAINTS also create constraint indexes<br />
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Move NOT NULL constraint information to pg_constraint<br />
|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?)<br />
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us<br />
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg01223.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00358.php<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add CREATE SCHEMA ... LIKE that copies a schema}}<br />
<br />
{{TodoItem<br />
|Fix CREATE OR REPLACE FUNCTION to not leave objects depending on the function in inconsistent state<br />
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow temporary tables to exist as empty by default in all sessions<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php <nowiki>idea: global temp tables</nowiki>]<br />
* [http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php <nowiki>Re: idea: global temp tables</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg01098.php <nowiki>global temporary tables</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2012-04/msg01148.php Temporary tables under hot standby]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the creation of "distinct" types<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php <nowiki>Distinct types</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider analyzing temporary tables when they are first used in a query<br />
|Autovacuum cannot analyze or vacuum temporary tables.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php <nowiki>autovacuum and temp tables support</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow an unlogged table to be changed to logged<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00437.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00323.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00237.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== UPDATE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|<nowiki>Allow UPDATE tab SET ROW (col, ...) = (SELECT...)</nowiki><br />
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg01308.php <nowiki>Re: [PATCHES] extension for sql update</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00865.php <nowiki>UPDATE using sub selects</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php <nowiki>UPDATE using sub selects</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php <nowiki>Re: UPDATE using sub selects</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00016.php <nowiki>Re: Do we need a TODO? (was Re: Concurrently updating anupdatable view)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows<br />
|This is related to the previous item, which questions whether it even has the right semantics<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ALTER ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Have ALTER TABLE RENAME of a SERIAL column rename the sequence<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CADLWmXUV4LbLhMZL8rYMhCy72aZZLB5BSARPQVgoX0BrxA0FFg@mail.gmail.com renaming implicit sequences]<br />
}}<br />
<br />
{{TodoItem<br />
|Have ALTER SEQUENCE RENAME rename the sequence name stored in the sequence table<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-09/msg00092.php <nowiki>BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00007.php <nowiki>Re: BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add ALTER DOMAIN to modify the underlying data type}}<br />
<br />
{{TodoItem<br />
|Allow ALTER TABLESPACE to move the tablespace to different directories}}<br />
<br />
{{TodoItem<br />
|Allow moving system tables to other tablespaces, where possible<br />
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}<br />
<br />
{{TodoItem<br />
|Have ALTER INDEX update the name of a constraint using that index}}<br />
<br />
{{TodoItem<br />
|Allow column display reordering by recording a display, storage, and permanent id for every column?<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php <nowiki>Column reordering in pg_dump</nowiki>]<br />
* http://archives.postgresql.org/message-id/1324412114-sup-9608@alvh.no-ip.org<br />
}}<br />
<br />
{{TodoItem<br />
|Allow deactivating (and reactivating) indexes via ALTER TABLE<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01191.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add ALTER OPERATOR ... RENAME<br />
|needs to consider effects of changing operator precedence<br />
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== CLUSTER ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Automatically maintain clustering on a table<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]<br />
* http://community.enterprisedb.com/git/<br />
* [http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php <nowiki>Re: maintain_cluster_order_v5.patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Allow CLUSTER to be used on a partial index<br />
* http://www.postgresql.org/message-id/CAMkU%3D1zYwoHHsqJ8wfK3GdG_t_a6t4RK-GFDSKymQ0EGP%3DtypA@mail.gmail.com<br />
}} <br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== COPY ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow COPY to report error lines and continue<br />
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure. <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY FROM to create index entries in bulk<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY in CSV mode to control whether a quoted zero-length string is treated as NULL<br />
|Currently this is always treated as a zero-length string, which generates an error when loading into an integer column <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php <nowiki>Re: [PATCHES] allow CSV quote in NULL</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve COPY performance<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01882.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY to report errors sooner<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY to handle other number formats<br />
|E.g. the German notation. Best would be something like WITH DECIMAL ','.<br />
}}<br />
<br />
{{TodoItem<br />
|Allow a stalled COPY to exit if the backend is terminated<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00067.php <nowiki>Re: possible bug not in open items</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY "text" format to output a header<br />
* http://www.postgresql.org/message-id/CACfv+pJ31tesLvncJyP24quo8AE+M0GP6p6MEpwPv6yV8%3DsVHQ@mail.gmail.com<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== GRANT/REVOKE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow SERIAL sequences to inherit permissions from the base table?}}<br />
<br />
{{TodoItem<br />
|Allow dropping of a role that has connection rights<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php <nowiki>DROP ROLE dependency tracking ...</nowiki>]<br />
}}<br />
{{TodoEndSubsection}}<br />
<br />
=== DECLARE CURSOR ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}<br />
<br />
{{TodoItem<br />
|Provide some guarantees about the behavior of cursors that invoke volatile functions<br />
* [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]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== INSERT ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow INSERT/UPDATE of the system-generated oid value for a row}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== SHOW/SET ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}<br />
<br />
{{TodoItem<br />
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count<br />
* [http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php <nowiki>Re: [ADMIN] shared_buffers and shmmax</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ANALYZE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}<br />
<br />
{{TodoItem<br />
|Have EXPLAIN ANALYZE report rows as floating-point numbers<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg01363.php <nowiki>explain analyze rows=%.0f</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00108.php <nowiki>Re: explain analyze rows=%.0f</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve how ANALYZE computes in-doubt tuples<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Window Functions ===<br />
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.<br />
{{TodoSubsection}}<br />
{{TodoItem<br />
|Support creation of user-defined window functions<br />
|We have the ability to create new window functions written in C. Is it<br />
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}<br />
<br />
{{TodoItem<br />
|Implement full support for window framing clauses<br />
|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.<br />
* RANGE BETWEEN ... PRECEDING/FOLLOWING<br />
* EXCLUDE<br />
}}<br />
<br />
{{TodoItem<br />
|Investigate tuplestore performance issues<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php <nowiki>tuplestore potential performance problem</nowiki>]<br />
}}<br />
<br />
{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}<br />
<br />
{{TodoItem<br />
|Teach planner to evaluate multiple windows in the optimal order<br />
|Currently windows are always evaluated in the query-specified order.<br />
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64<br />
}}<br />
<br />
{{TodoItem<br />
|Implement DISTINCT clause in window aggregates<br />
|Some proprietary RDBMSs have implemented it already, so it helps with porting from those.}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Integrity Constraints ==<br />
=== Keys ===<br />
<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve deferrable unique constraints for cases with many conflicts<br />
|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.<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Referential Integrity ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add MATCH PARTIAL referential integrity}}<br />
<br />
{{TodoItem<br />
|Change foreign key constraint for array -&gt; element to mean element in array?<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-10/msg01814.php <nowiki>foreign keys for array/period contains relationships</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Are ri_KeysEqual checks in the RI enforcement triggers still necessary?<br />
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Check Constraints ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Run check constraints only when affected columns are changed<br />
* http://archives.postgresql.org/message-id/1326055327.15293.13.camel@vanquo.pezone.net<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Server-Side Languages ==<br />
<br />
{{TodoItem<br />
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}<br />
<br />
{{TodoItem<br />
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}<br />
<br />
{{TodoItem<br />
|Add more fine-grained specification of functions taking arbitrary data types<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php <nowiki>RfD: more powerful &quot;any&quot; types</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement stored procedures<br />
|This might involve the control of transaction state and the return of multiple result sets<br />
* [http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php <nowiki>PL/pgSQL stored procedure returning multiple result sets (SELECTs)?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php <nowiki>Gathering specs and discussion on feature (post 9.1)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow holdable cursors in SPI}}<br />
<br />
=== SQL-Language Functions ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Rethink query plan caching and timing of parse analysis within SQL-language functions<br />
|They should work more like plpgsql functions do ...<br />
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00078.php <nowiki>Re: BUG #6019: invalid cached plan on inherited table</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/pgSQL ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}<br />
<br />
{{TodoItem<br />
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki><br />
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow row and record variables to be set to NULL constants, and allow NULL tests on such variables<br />
|Because a row is not scalar, do not allow assignment from NULL-valued scalars.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider keeping separate cached copies when search_path changes<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of NULL row values vs. NULL rows<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php <nowiki>Null row vs. row of nulls in plpgsql</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01973.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve PERFORM handling of WITH queries or document limitation<br />
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00309.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/Perl ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow regex operations in plperl using UTF8 characters in non-UTF8 encoded databases}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/Python ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Develop a trusted variant of PL/Python.}}<br />
<br />
{{TodoItem<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-02/msg01468.php <nowiki>Re: pl/python do not delete function arguments</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a DB-API compliant interface on top of the SPI interface<br />
* http://petereisentraut.blogspot.com/2011/11/plpydbapi-db-api-for-plpython.html<br />
}}<br />
<br />
{{TodoItem<br />
|For functions returning a setof record with a composite type, cache the I/O functions for the composite type<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02007.php<br />
}}<br />
<br />
{{TodoItemDone<br />
|Fix loss of information during conversion of numeric type to Python float}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/Tcl ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add table function support}}<br />
<br />
{{TodoItem<br />
|Check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, and SPI calls.}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Clients ==<br />
<br />
{{TodoItem<br />
|Add a function like pg_get_indexdef() that report more detailed index information<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Split out pg_resetxlog output into pre- and post-sections<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php<br />
}}<br />
<br />
=== pg_ctl ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve pg_ctl's detection of running postmasters<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00000.php<br />
* http://archives.postgresql.org/pgsql-committers/2011-06/msg00001.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add additional shutdown modes, and change the default?<br />
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg01283.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== psql ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Have psql \ds show all sequences and their settings<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00916.php <nowiki>Re: TODO item: Have psql show current values for a sequence</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00401.php <nowiki>Quick patch: Display sequence owner</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Move psql backslash database information into the backend, use mnemonic commands?<br />
|This would allow non-psql clients to pull the same information out of the database as psql. <br />
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Make psql's \d commands more consistent in their handling of schemas<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php <nowiki>Re: psql and schemas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Make psql's \d commands distinguish default privileges from no privileges<br />
|ACL displays were visibly different for the two cases before we "improved" them by using array_to_string.<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consistently display privilege information for all objects in psql}}<br />
<br />
{{TodoItemEasy<br />
|\s without arguments (display history) fails with libedit, doesn't use pager either<br />
* [http://archives.postgresql.org/pgsql-bugs/2011-06/msg00114.php <nowiki> psql \s not working - OS X</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a \set variable to control whether \s displays line numbers<br />
|Another option is to add \# which lists line numbers, and allows command execution.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Include the symbolic SQLSTATE name in verbose error reports<br />
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add prompt escape to display the client and server versions<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.<br />
|Currently, &quot;wrapped&quot; format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]<br />
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}<br />
<br />
{{TodoItem<br />
|Support the ReST table output format<br />
|Details about the ReST format: http://docutils.sourceforge.net/rst.html#reference-documentation<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg01007.php <nowiki>Proposal: new border setting in psql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00518.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00609.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add option to print advice for people familiar with other databases<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php <nowiki>MySQL-ism help patch for psql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add ability to edit views with \ev<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00023.php <nowiki>Adding \ev view editor?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php<br />
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent psql from sending remaining single-line multi-statement queries after reconnecting<br />
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php<br />
}}<br />
<br />
{{TodoItemEasy<br />
|Add \i option to bring in the specified file as a quoted literal<br />
|This would be useful for creating functions and other areas. Details still need to be worked out.<br />
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00016.php<br />
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00020.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having psql -c read .psqlrc, for consistency<br />
|psql -f already reads .psqlrc<br />
}}<br />
<br />
{{TodoItem<br />
|Allow processing of multiple -f (file) options<br />
* http://www.postgresql.org/message-id/AANLkTikFpzrTRl6392GhatQdwlCWQTXFdSMxh5CP51iv@mail.gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Improve line drawing characters<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00386.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider improving the continuation prompt<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01772.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve speed of tab completion by using LIKE<br />
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== pg_dump / pg_restore ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItemEasy<br />
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}<br />
<br />
{{TodoItemEasy<br />
|Modify pg_dump to create skeleton views for reload (which are then updated via CREATE OR REPLACE VIEW) when views have circular dependencies. This should eliminate the need for the CREATE RULE "_RETURN" hack currently used to address this issue. Thread and additional information here:<br />
* [http://www.postgresql.org/message-id/25554.1360895028@sss.pgh.pa.us Description of change]<br />
|}}<br />
<br />
{{TodoItem<br />
|Add pg_dumpall custom format dumps?<br />
* [http://archives.postgresql.org/pgsql-general/2010-05/msg00509.php pg_dumpall custom format]<br />
|}}<br />
<br />
{{TodoItem<br />
|Avoid using platform-dependent locale names in pg_dumpall output<br />
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get<br />
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.<br />
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|In a selective dump, allow dumping of an object and all its dependencies}}<br />
<br />
{{TodoItem<br />
|Add options like pg_restore -l and -L to pg_dump}}<br />
<br />
{{TodoItem<br />
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}<br />
<br />
{{TodoItem<br />
|Allow pg_dump --clean to drop roles that own objects or have privileges<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}<br />
<br />
{{TodoItem<br />
|Remove support for dumping from pre-7.3 servers<br />
|In 7.3 and later, we can get accurate dependency information from the server. pg_dump still contains a lot of crufty code<br />
to try to deal with the lack of dependency info in older servers, but the usefulness of maintaining that code grows small.}}<br />
<br />
{{TodoItem<br />
|Refactor handling of database attributes between pg_dump and pg_dumpall<br />
|Currently only pg_dumpall emits database attributes, such as ALTER DATABASE SET commands and database-level GRANTs.<br />
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,<br />
but it's unclear whether that will satisfy the demand.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2010-05/msg00010.php summary of the issues]<br />
}}<br />
<br />
{{TodoItem<br />
|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.<br />
|This will require new backend syntax, perhaps COMMENT ON CURRENT DATABASE. This is related to the previous item.}}<br />
<br />
{{TodoItem<br />
|Allow parallel restore of tar dumps<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-02/msg01154.php <nowiki>Re: parallel restore</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Preserve sparse storage of large objects over dump/restore<br />
* [http://archives.postgresql.org/message-id/18789.1349750451@sss.pgh.pa.us <nowiki>TODO item: teach pg_dump about sparsely-stored large objects</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ecpg ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Docs<br />
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}<br />
<br />
{{TodoItem<br />
|Solve cardinality &gt; 1 for input descriptors / variables?}}<br />
<br />
{{TodoItem<br />
|Add a semantic check level, e.g. check if a table really exists}}<br />
<br />
{{TodoItem<br />
|fix handling of DB attributes that are arrays}}<br />
<br />
{{TodoItem<br />
|Fix nested C comments}}<br />
<br />
{{TodoItemEasy<br />
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}<br />
<br />
{{TodoItem<br />
|Make SET CONNECTION thread-aware, non-standard?}}<br />
<br />
{{TodoItem<br />
|Allow multidimensional arrays}}<br />
<br />
{{TodoItem<br />
|Implement COPY FROM STDIN}} <br />
<br />
{{TodoItem<br />
|Provide a way to specify size of a bytea parameter<br />
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]<br />
}}<br />
<br />
{{TodoItemEasy<br />
|Fix small memory leaks in ecpg<br />
|Memory leaks in a short running application like ecpg are not really a problem, but make debugging more complicated}} <br />
<br />
{{TodoItem<br />
|Allow reuse of cursor name variables<br />
* [http://archives.postgresql.org/message-id/20100329113435.GA3430@feivel.credativ.lan <nowiki>Problems with variable cursorname in ecpg</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== libpq ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Prevent PQfnumber() from lowercasing unquoted column names<br />
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}<br />
<br />
{{TodoItem<br />
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add PQexecf() that allows complex parameter substitution<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add SQLSTATE and severity to errors generated within libpq itself<br />
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01425.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for interface/ipaddress binding to libpq<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php <nowiki>SR/libpq - outbound interface/ipaddress binding</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== HTTP===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow access to the database via HTTP<br />
|See [[HTTP_API]]}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Triggers ==<br />
<br />
{{TodoItem<br />
|Improve storage of deferred trigger queue<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php <nowiki>Scaling up deferred unique checks and the after trigger queue</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00023.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow triggers to be disabled in only the current session.<br />
|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.}}<br />
<br />
{{TodoItem<br />
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY<br />
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}<br />
<br />
{{TodoItem<br />
|Allow statement-level triggers to access modified rows}}<br />
<br />
{{TodoItem<br />
|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<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php <nowiki>Statement-level triggers and inheritance</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Tighten trigger permission checks<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow BEFORE INSERT triggers on views<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add database and transaction-level triggers<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce locking requirements for creating a trigger<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php <nowiki>Re: Change lock requirements for adding a trigger</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid requirement for "AFTER" trigger functions to return a value<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02384.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow creation of inline triggers<br />
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00708.php<br />
}}<br />
<br />
== Inheritance ==<br />
<br />
{{TodoItem<br />
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-05/msg00285.php <nowiki>Partitioning/inherited tables vs FKs</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00039.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00305.php<br />
}}<br />
<br />
{{TodoItem<br />
|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<br />
|The main difficulty with this item is the problem of creating an index that can span multiple tables.}}<br />
<br />
{{TodoItem<br />
|Determine whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY). If yes, implement it.}}<br />
<br />
{{TodoItem<br />
|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.}}<br />
<br />
== Indexes ==<br />
<br />
{{TodoItem<br />
|Prevent index uniqueness checks when UPDATE does not modify the column<br />
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.<br />
However, HOT already short-circuits this in common cases, so more work might not be helpful.<br />
* http://www.postgresql.org/message-id/CA+TgmoZOyaTanfEvNUdiHBCuu9Zh0JVP1e_UTVbx6Rvj9vFC9Q@mail.gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php <nowiki>Bitmap Indexes: request for feedback</nowiki>]<br />
* http://archives.postgresql.org/message-id/800923.27831.qm@web29010.mail.ird.yahoo.com <br />
}}<br />
<br />
{{TodoItem<br />
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics<br />
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02179.php <br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00459.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02054.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01731.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00894.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00679.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having a larger statistics target for indexed columns and expression indexes. <br />
}}<br />
<br />
{{TodoItem<br />
|Consider smaller indexes that record a range of values per heap page, rather than having one index entry for every heap row<br />
|This is useful if the heap is clustered by the indexed values. <br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00341.php <nowiki>Grouped Index Tuples</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01264.php <nowiki>Grouped Index Tuples</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00465.php <nowiki>Grouped Index Tuples / Clustered Indexes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php <nowiki>Bitmapscan changes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php <nowiki>Re: GIT patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php <nowiki>Re: Index Tuple Compression Approach?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php <nowiki>Re: Index AM change proposals, redux</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00911.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg00128.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multiple indexes to be created concurrently, ideally via a single heap scan<br />
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.<br />
Cluster could definitely benefit from this.<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00093.php<br />
* http://www.postgresql.org/message-id/CADVWZZJ5AS%3DXVrDwfTQqQP_V1+_fTYcZhq%3Dd5CbCXoALCjObbg@mail.gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Consider sorting entries before inserting into btree index<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow creation of an index that can do comparisons to test if a value is between two column values<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00757.php <nowiki>Proposal: temporal extension &quot;period&quot; data type</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider using "effective_io_concurrency" for index scans<br />
|Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.<br />
* [http://www.postgresql.org/message-id/CAGTBQpZzf70n0PYJ%3DVQLd+jb3wJGo%3D2TXmY+SkJD6G_vjC5QNg@mail.gmail.com Prefetch index pages for B-Tree index scans]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix problem with btree page splits during checkpoints<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00052.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00184.php<br />
}}<br />
<br />
{{TodoItem<br />
|[http://archives.postgresql.org/pgsql-hackers/2012-05/msg00669.php Support amgettuple() in GIN (useful for exclusion constraints)]<br />
}}<br />
<br />
{{TodoItem<br />
| Allow "loose" or "skip" scans on btree indexes in which the first column has low cardinality<br />
* http://archives.postgresql.org/pgsql-performance/2012-08/msg00159.php<br />
}}<br />
<br />
{{TodoItem<br />
| Make the planner's "special index operator" mechanism extensible<br />
* http://www.postgresql.org/message-id/27270.1364700924@sss.pgh.pa.us<br />
}}<br />
<br />
<br />
=== GIST ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add more GIST index support for geometric data types}}<br />
<br />
{{TodoItem<br />
|Allow GIST indexes to create certain complex index types, like digital trees (see Aoki)}}<br />
<br />
{{TodoItem<br />
|Fix performance issues in contrib/seg and contrib/cube GiST support<br />
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]<br />
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]<br />
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00069.php <nowiki>Re: GiST index performance</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-performance/2009-06/msg00068.php <nowiki>GiST index performance</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|[http://archives.postgresql.org/message-id/4DC8D284-05CF-4E3D-9670-AC9A32C37A36@justatheory.com GiST index support for arrays]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Hash ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add UNIQUE capability to hash indexes}}<br />
<br />
{{TodoItem<br />
|Add hash WAL logging for crash recovery<br />
* http://archives.postgresql.org/pgsql-performance/2011-09/msg00196.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multi-column hash indexes}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Sorting ==<br />
<br />
{{TodoItem<br />
|Consider whether duplicate keys should be sorted by block/offset<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider being smarter about memory and external files used during sorts<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php <nowiki>Re: Sorting Improvements for 8.4</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider detoasting keys before sorting}}<br />
<br />
{{TodoItemDone<br />
|Allow sorts to use more available memory<br />
* http://archives.postgresql.org/pgsql-hackers/2007-11/msg01026.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01123.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg01957.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow sorts of skinny tuples to use even more available memory.<br />
* Now that it is not limited by MaxAllocSize, don't limit by INT_MAX either.<br />
* http://www.postgresql.org/message-id/CA+U5nMKkRMin1pV8VMpS6_n7hcOWSG0kZS3oFL9JOa8DV6vJyQ@mail.gmail.com<br />
}}<br />
<br />
== Fsync ==<br />
<br />
{{TodoItem<br />
|Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether fsync does anything<br />
|Ideally this requires a separate test program like /contrib/pg_test_fsync that can be run at initdb time or optionally later.<br />
}}<br />
<br />
{{TodoItem<br />
|Consider sorting writes during checkpoint<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php <nowiki>Re: Sorting writes during checkpoint</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg02012.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00278.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00493.php<br />
}}<br />
<br />
== Cache Usage ==<br />
<br />
{{TodoItem<br />
|Provide a way to calculate an &quot;estimated COUNT(*)&quot;<br />
|Perhaps by using the optimizer's cardinality estimates or random sampling.<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php <nowiki>Re: Improving count(*)</nowiki>]<br />
* http://wiki.postgresql.org/wiki/Slow_Counting<br />
}}<br />
<br />
{{TodoItem<br />
|Consider automatic caching of statements at various levels:<br />
* Parsed query tree<br />
* Query execute plan<br />
* Query results <br />
<br />
:<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider increasing internal areas (NUM_CLOG_BUFFERS) when shared buffers is increased<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php <nowiki>Re: slru.c race condition (was Re: TRAP: FailedAssertion(&quot;!((itemid)-&gt;lp_flags &amp; 0x01)&quot;,)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php <nowiki>clog_buffers to 64 in 8.3?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php <nowiki>CLOG Patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider decreasing the amount of memory used by PrivateRefCount<br />
|<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php <nowiki>PrivateRefCount (for 8.3)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php <nowiki>Re: PrivateRefCount (for 8.3)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider allowing higher priority queries to have referenced buffer cache pages stay in memory longer<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve cache lookup speed for sessions accessing many relations<br />
* http://archives.postgresql.org/pgsql-hackers/2012-11/msg00356.php<br />
}}<br />
<br />
== Vacuum ==<br />
<br />
{{TodoItem<br />
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow concurrent inserts to use recently created pages rather than creating new ones<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having single-page pruning update the visibility map<br />
* <nowiki>https://commitfest.postgresql.org/action/patch_view?id=75</nowiki><br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php <nowiki>Re: visibility maps and heap_prune</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]<br />
}}<br />
<br />
{{TodoItem<br />
|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<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php <nowiki>FSM search modes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a more compact data representation for dead tuple locations within VACUUM<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide more information in order to improve user-side estimates of dead space bloat in relations<br />
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve locking behaviour of vacuum during trailing page truncation<br />
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00319.php<br />
* http://archives.postgresql.org/message-id/4D8DF88E.7080205@Yahoo.com<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce the number of table scans performed by vacuum<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00605.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php<br />
}}<br />
<br />
{{TodoItem<br />
|Vacuum Gin indexes in physically order rather than logical order<br />
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg00443.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid creation of the free space map for small tables<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg01751.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00552.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00615.php<br />
}}<br />
<br />
=== Auto-vacuum ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItemEasy<br />
|Issue log message to suggest VACUUM FULL if a table is nearly empty?}}<br />
<br />
{{TodoItem<br />
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation<br />
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can do that. <br />
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent autovacuum from running if an old transaction is still running from the last vacuum<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have autoanalyze of parent tables occur when child tables are modified<br />
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php<br />
* http://archives.postgresql.org/pgsql-performance/2010-10/msg00271.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow visibility map all-visible bits to be set even when an auto-ANALYZE is running<br />
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00356.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow parallel cores to be used by vacuumdb<br />
* [http://archives.postgresql.org/message-id/4F10A728.7090403@agliodbs.com vacuumdb -j]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve autovacuum tuning<br />
* http://www.postgresql.org/message-id/5078AD6B.8060802@agliodbs.com<br />
* http://www.postgresql.org/message-id/20130124215715.GE4528@alvh.no-ip.org<br />
}}<br />
<br />
{{TodoItem<br />
|Improve setting of visibility map bits for read-only and insert-only workloads<br />
* http://www.postgresql.org/message-id/20130906001437.GA29264@momjian.us<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Locking ==<br />
<br />
{{TodoItem<br />
|Fix priority ordering of read and write light-weight locks<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php <nowiki>lwlocks and starvation</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php <nowiki>Re: lwlocks and starvation</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow UPDATEs on only non-referential integrity columns not to conflict with referential integrity locks<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php <nowiki>Referential Integrity and SHARE locks</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add idle_in_transaction_timeout GUC so locks are not held for long periods of time}}<br />
<br />
{{TodoItem<br />
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Detect deadlocks involving LockBufferForCleanup()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow finer control over who is cancelled in a deadlock<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01727.php<br />
}}<br />
<br />
== Startup Time Improvements ==<br />
<br />
{{TodoItem<br />
|Experiment with multi-threaded backend for backend creation<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow backends to change their database without restart<br />
|This allows for faster server startup.<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00843.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00336.php<br />
}}<br />
<br />
== Write-Ahead Log ==<br />
<br />
{{TodoItem<br />
|Eliminate need to write full pages to WAL before page modification<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01191.php<br />
* [http://archives.postgresql.org/message-id/20120105061916.GB21048@fetter.org WIP double writes]<br />
* [http://archives.postgresql.org/message-id/4EFC449F02000025000441CD@gw.wicourts.gov double writes]<br />
* [http://archives.postgresql.org/message-id/20120110214344.GB21106@fetter.org Double-write with Fast Checksums]<br />
* [http://archives.postgresql.org/message-id/1962493974.656458.1327703514780.JavaMail.root@zimbra-prod-mbox-4.vmware.com double writes using "double-write buffer" approach]<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01463.php<br />
}}<br />
<br />
{{TodoItem<br />
|When full page writes are off, write CRC to WAL and check file system blocks on recovery<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Write full pages during file system write and not when the page is modified in the buffer cache<br />
|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.<br />
* [http://archives.postgresql.org/message-id/CAGvK12UST-tPhyLrSLuSpwFxZbAO79yYrhV2xaLmS2MkUxNUVQ@mail.gmail.com Page Checksums + Double Writes]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce WAL traffic so only modified values are written rather than entire rows<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php <nowiki>Reduction in WAL for UPDATEs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow WAL information to recover corrupted pg_controldata<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Find a way to reduce rotational delay when repeatedly writing last WAL page<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php <nowiki>500 tpsQL + WAL log implementation</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Speed WAL recovery by allowing more than one page to be prefetched<br />
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay. <br />
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve WAL concurrency by increasing lock granularity<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Be more aggressive about creating WAL files<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php <nowiki>Re: PANIC caused by open_sync on Linux</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-07/msg01075.php <nowiki>PreallocXlogFiles</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-04/msg00556.php <nowiki>WAL/PITR additional items</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have resource managers report the duration of their status changes<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Close deleted WAL files held open in *nix by long-lived read-only backends<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]<br />
}}<br />
<br />
== Optimizer / Executor ==<br />
<br />
{{TodoItem<br />
|Improve selectivity functions for geometric operators}}<br />
<br />
{{TodoItem<br />
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold<br />
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00597.php<br />
}}<br />
<br />
{{TodoItem<br />
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}<br />
<br />
{{TodoItem<br />
|Consider compressed annealing to search for query plans<br />
|This might replace GEQO.<br />
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Improve use of expression indexes for ORDER BY <br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php <nowiki>Resjunk sort columns, Heikki's index-only quals patch, and bug #5000</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Modify the planner to better estimate caching effects<br />
* http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow shared buffer cache contents to affect index cost computations<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the CTE (Common Table Expression) optimization fence to be optionally disabled<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00700.php<br />
* http://archives.postgresql.org/pgsql-performance/2012-11/msg00161.php<br />
}}<br />
<br />
{{TodoItem<br />
|Teach the planner how to better use partial indexes for index-only scans<br />
* http://www.postgresql.org/message-id/25141.1345072858@sss.pgh.pa.us<br />
* http://www.postgresql.org/message-id/79C7D74D-59B0-4D97-A5E5-55553EF299AA@justatheory.com<br />
}}<br />
<br />
=== Hashing ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Consider using a hash for joining to a large IN (VALUES ...) list<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow single batch hash joins to preserve outer pathkeys<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|"lazy" hash tables - look up only the tuples that are actually requested<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid building the same hash table more than once during the same query<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid hashing for distinct and then re-hashing for hash join<br />
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Background Writer ==<br />
<br />
{{TodoItem<br />
|Consider having the background writer update the transaction status hint bits before writing out the page<br />
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.}}<br />
<br />
{{TodoItem<br />
|Consider adding buffers the background writer finds reusable to the free list <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]<br />
}}<br />
<br />
{{TodoItem<br />
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency<br />
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]<br />
}}<br />
<br />
== Concurrent Use of Resources ==<br />
<br />
{{TodoItem<br />
|Do async I/O for faster random read-ahead of data<br />
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]<br />
* [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>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]<br />
* [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>]<br />
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.<br />
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]<br />
}}<br />
<br />
{{TodoItem<br />
|Experiment with multi-threaded backend for better I/O utilization<br />
|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.<br />
* http://archives.postgresql.org/pgsql-performance/2011-02/msg00123.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01139.php<br />
}}<br />
<br />
{{TodoItem<br />
|Experiment with multi-threaded backend for better CPU utilization<br />
|This would allow several CPUs to be used for a single query, such as for sorting or query execution.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00945.php <nowiki>Multi CPU Queries - Feedback and/or suggestions wanted!</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|SMP scalability improvements<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]<br />
}}<br />
<br />
== TOAST ==<br />
<br />
{{TodoItem<br />
|Allow user configuration of TOAST thresholds<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce unnecessary cases of deTOASTing<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce costs of repeat de-TOASTing of values<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]<br />
}}<br />
<br />
== Monitoring ==<br />
{{TodoItem<br />
|Expand pg_stat_activity for easier integration with monitoring tools<br />
|* http://archives.postgresql.org/message-id/4DFA13A5.2060200@2ndQuadrant.com<br />
}}<br />
<br />
{{TodoItem<br />
|Add column to pg_stat_activity that shows the progress of long-running commands like CREATE INDEX and VACUUM<br />
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00203.php <nowiki>EXPLAIN progress info</nowiki>]<br />
* The CLUSTER/VACUUM FULL implementation would also be useful to track this way<br />
}}<br />
<br />
{{TodoItem<br />
|Have pg_stat_activity display query strings in the correct client encoding<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php <nowiki>pg_stats queries versus per-database encodings</nowiki>]<br />
}}<br />
<br />
{{TodoItemEasy<br />
|Expose pg_controldata via an SQL interface<br />
|Helpful for monitoring replicated databases<br />
* http://archives.postgresql.org/message-id/4B901D73.8030003@agliodbs.com<br />
* [http://archives.postgresql.org/message-id/4B959D7A.6010907@joeconway.com initial patch]<br />
}}<br />
<br />
{{TodoItem<br />
| Add entry creation timestamp column to pg_stat_replication<br />
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00694.php<br />
}}<br />
<br />
{{TodoItem<br />
| Allow reporting of stalls due to wal_buffer wrap-around<br />
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00826.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure pg_stat_database columns tup_returned and tup_fetched to return meaningful values<br />
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org<br />
}}<br />
<br />
== Miscellaneous Performance ==<br />
<br />
{{TodoItem<br />
|Use mmap() rather than shared memory for shared buffers?<br />
|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.<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00750.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00756.php<br />
}}<br />
<br />
{{TodoItem<br />
|Rather than consider mmap()-ing in 8k pages, consider mmap()'ing entire files into a backend?<br />
|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.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01239.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider ways of storing rows more compactly on disk:<br />
* Reduce the row header size?<br />
* Consider reducing on-disk varlena length from four bytes to two because a heap row cannot be more than 64k in length}}<br />
<br />
{{TodoItem<br />
|Consider transaction start/end performance improvements<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php <nowiki>Reducing Transaction Start/End Contention</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow configuration of backend priorities via the operating system<br />
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.<br />
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider increasing the minimum allowed number of shared buffers<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call<br />
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation<br />
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Sort large UPDATE/DELETEs so it is done in heap order<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider decreasing the I/O caused by updating tuple hint bits<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid the requirement of freezing pages that are infrequently modified <br />
|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<br />
* http://archives.postgresql.org/message-id/4BF701CF.2090205@agliodbs.com<br />
* http://archives.postgresql.org/pgsql-hackers/2010-06/msg00082.php<br />
* http://www.postgresql.org/message-id/20130523175148.GA29374@alap2.anarazel.de<br />
* http://www.postgresql.org/message-id/CA+TgmoaEmnoLZmVbb8gvY69NA8zw9BWpiZ9+TLz-LnaBOZi7JA@mail.gmail.com<br />
* http://www.postgresql.org/message-id/51A7553E.5070601@vmware.com<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode<br />
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Restructure truncation logic to be more resistant to failure<br />
|This also involves not writing dirty buffers for a truncated or dropped relation<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider adding logic to increase large tables by more than 8k<br />
|This would reduce file system fragmentation<br />
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00337.php<br />
}}<br />
<br />
== Miscellaneous Other ==<br />
<br />
{{TodoItem<br />
|Deal with encoding issues for filenames in the server filesystem<br />
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}<br />
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}<br />
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}<br />
}}<br />
<br />
{{TodoItem<br />
|Deal with encoding issues in the output of localeconv()<br />
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]<br />
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]<br />
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports<br />
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]<br />
* [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>]<br />
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add 64-bit support to /contrib/pgbench<br />
* http://archives.postgresql.org/pgsql-hackers/2010-07/msg00153.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00705.php<br />
}}<br />
<br />
{{TodoItem<br />
|Use sa_mask to close race conditions between signal handlers<br />
* http://www.postgresql.org/message-id/20130911013107.GA225735@tornado.leadboat.com<br />
}}<br />
<br />
== Source Code ==<br />
<br />
{{TodoItemEasy<br />
|Remove warnings created by -Wcast-align}}<br />
<br />
{{TodoItem<br />
|Move platform-specific ps status display info from ps_status.c to ports}}<br />
<br />
{{TodoItem<br />
|Consider a faster CRC32 algorithm<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow cross-compiling by generating the zic database on the target system}}<br />
<br />
{{TodoItem<br />
|Improve NLS maintenance of libpgport messages linked onto applications}}<br />
<br />
{{TodoItem<br />
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}<br />
<br />
{{TodoItem<br />
|Allow creation of universal binaries for Darwin<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider GnuTLS if OpenSSL license becomes a problem<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php<br />
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider making NAMEDATALEN more configurable in future releases}}<br />
<br />
{{TodoItem<br />
|Research use of signals and sleep wake ups<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow C++ code to more easily access backend code<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider simplifying how memory context resets handle child contexts<br />
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Create three versions of libpgport to simplify client code<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement the non-threaded Avahi service discovery protocol<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce data row alignment requirements on some 64-bit systems<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Restructure TOAST internal storage format for greater flexibility<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Add regression tests for pg_dump/restore<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01967.php <nowiki>"make install-check-pg_dump" target in src/regress]</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Research different memory allocation methods for lists<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php <br />
}}<br />
<br />
{{TodoItem<br />
| Consider removing the attribute options cache<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00039.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure /contrib section<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00705.php<br />
}}<br />
<br />
{{TodoItem<br />
| Consider adding explicit huge page support<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00123.php<br />
}}<br />
<br />
=== /contrib/pg_upgrade ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Handle large object comments<br />
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.<br />
}}<br />
<br />
{{TodoItem<br />
|Consider using pg_depend for checking object usage in version.c<br />
}}<br />
<br />
{{TodoItem<br />
|If reindex is necessary, allow it to be done in parallel with pg_dump custom format<br />
}}<br />
<br />
{{TodoItem<br />
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary<br />
|pg_class.oid is not preserved so schema.tablename must be used.<br />
* [http://archives.postgresql.org/message-id/CAAZKuFaWdLkK8eozSAooZBets9y_mfo2HS6urPAKXEPbd-JLCA@mail.gmail.com pg_upgrade and statistics]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve testing, perhaps using the buildfarm<br />
|The buildfarm has access to multiple versions of PostgreSQL.<br />
}}<br />
<br />
{{TodoItem<br />
|Create machine-readable output of pg_controldata<br />
|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.<br />
}}<br />
<br />
{{TodoItem<br />
|Find cleaner way to start/stop dedicated servers for upgrades<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00275.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a way to run pg_upgrade on standby servers<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00453.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00056.php<br />
}}<br />
<br />
{{TodoItem<br />
|Desired changes that would prevent upgrades with pg_upgrade<br />
* 32-bit page checksums<br />
* Add metapage to GiST indexes<br />
* Clean up hstore's internal representation<br />
* Remove tuple infomask bit HEAP_MOVED_OFF and HEAP_MOVED_IN<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Windows ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Remove configure.in check for link failure when cause is found}}<br />
<br />
{{TodoItem<br />
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}<br />
<br />
{{TodoItem<br />
|Allow psql to use readline once non-US code pages work with backslashes}}<br />
<br />
{{TodoItem<br />
|Fix problem with shared memory on the Win32 Terminal Server}}<br />
<br />
{{TodoItem<br />
|Improve signal handling<br />
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Convert MSVC build system to remove most batch files<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support pgxs when using MSVC}}<br />
<br />
{{TodoItem<br />
|Fix MSVC NLS support, like for to_char()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Find a correct rint() substitute on Windows<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix global namespace issues when using multiple terminal server sessions<br />
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}<br />
<br />
{{TodoItem<br />
|Change from the current autoconf/gmake build system to cmake<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve consistency of path separator usage<br />
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net<br />
}}<br />
<br />
{{TodoItem<br />
|Fix cross-compiling on Windows<br />
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce file statistics overhead on directory reads<br />
* http://www.postgresql.org/message-id/1338325561.82125.YahooMailNeo@web39304.mail.mud.yahoo.com<br />
}}<br />
<br />
<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Wire Protocol Changes ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow dynamic character set handling}}<br />
<br />
{{TodoItem<br />
|Let the client indicate character encoding of database names, user names, and passwords<br />
* http://www.postgresql.org/message-id/16160.1360540050@sss.pgh.pa.us}}<br />
<br />
{{TodoItem<br />
|Add decoded type, length, precision}}<br />
<br />
{{TodoItem<br />
|Mark result columns as known-not-null when possible<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide more control over planner treatment of statements being prepared}}<br />
<br />
{{TodoItem<br />
|Use compression<br />
|If SSL is used, hopefully avoid the overhead of key negotiation and encryption<br />
* http://archives.postgresql.org/pgsql-hackers/2012-06/msg00793.php<br />
}}<br />
<br />
{{TodoItem<br />
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}<br />
<br />
{{TodoItem<br />
|Set protocol for wire format negotiation<br />
* [http://archives.postgresql.org/message-id/CACMqXCKkGrGXxQhjHCKCe0B8hn6sTt-1sdgHZOSGQMxrusOsQA@mail.gmail.com GUC_REPORT for protocol tunables]<br />
}}<br />
<br />
{{TodoItem<br />
|Make sure upgrading to a 4.1 protocol version will actually work smoothly<br />
* [http://archives.postgresql.org/message-id/28307.1318255008@sss.pgh.pa.us Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multi-state authentication<br />
* http://www.postgresql.org/message-id/51A44185.5060306@2ndquadrant.com<br />
}}<br />
<br />
{{TodoItem<br />
|Identify the affected object in CommandComplete message?<br />
* http://www.postgresql.org/message-id/CAAfz9KNGVoyM+z_2tnPKTDXG_RdR9a33Y5s+zQ9LdwTTsqqZng@mail.gmail.com<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Documentation ==<br />
<br />
{{TodoItemEasy <br />
| Add contrib functions to the index<br />
* Add the functions and GUCs in the contrib modules to [http://www.postgresql.org/docs/current/static/sql-createindex.html the documentation index]: [http://archives.postgresql.org/message-id/50A2E173.6030404@2ndQuadrant.com per list discussion]<br />
}}<br />
<br />
{{TodoItem<br />
|Convert single quotes to apostrophes in the PDF documentation<br />
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide a manpage for postgresql.conf<br />
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}<br />
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}<br />
}}<br />
<br />
{{TodoItem<br />
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools<br />
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}<br />
}}<br />
<br />
{{TodoItem<br />
|Consider changing documentation format from SGML to XML<br />
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]<br />
* http://archives.postgresql.org/pgsql-docs/2011-04/msg00020.php<br />
* http://wiki.postgresql.org/wiki/Switching_PostgreSQL_documentation_from_SGML_to_XML<br />
}}<br />
<br />
{{TodoItem<br />
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard<br />
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com<br />
}}<br />
<br />
{{TodoItem<br />
|Add diagrams to the documentation<br />
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php<br />
}}<br />
<br />
== Exotic Features ==<br />
<br />
{{TodoItem<br />
|Add pre-parsing phase that converts non-ISO syntax to supported syntax<br />
|This could allow SQL written for other databases to run without modification.}}<br />
<br />
{{TodoItem<br />
|Allow plug-in modules to emulate features from other databases}}<br />
<br />
{{TodoItem<br />
|Add features of Oracle-style packages<br />
|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 &quot;packages&quot; syntax at all.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider allowing control of upper/lower case folding of unquoted identifiers<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]<br />
* [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>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add autonomous transactions<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Give query progress indication<br />
* [[Query progress indication]]<br />
}}<br />
<br />
{{TodoItem<br />
|Rethink our type system<br />
* [[Rethinking datatypes]]<br />
}}<br />
<br />
== Features We Do ''Not'' Want ==<br />
<br />
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.<br />
<br />
{{TodoItem<br />
|All backends running as threads in a single process (not wanted)<br />
|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.}}<br />
<br />
{{TodoItem<br />
|"Oracle-style" optimizer hints (not wanted)<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Embedded server (not wanted)<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Obfuscated function source code (not wanted)<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Indeterminate behavior for the GROUP BY clause (not wanted)<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]<br />
}}<br />
<br />
</div><br />
<br />
[[Category:Todo]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=Todo&diff=20518Todo2013-08-05T17:17:33Z<p>Theory: Add item for allowing a comma to denote fractional seconds.</p>
<hr />
<div><div style="margin: 1ex 1em; float: right;"><br />
__TOC__<br />
</div><br />
<br />
This list contains '''known PostgreSQL bugs and feature requests''' and we hope it is complete. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].<br />
<br />
* {{TodoPending}} - marks ordinary, incomplete items<br />
* {{TodoEasy}} - marks items that are easier to implement<br />
* {{TodoDone}} - marks changes that are done, and will appear in the PostgreSQL 9.4 release.<br />
<br />
For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the mailing list.</b><br />
<br />
<b>For Developers:</b> 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:<br />
<br />
Desirability -> Design -> Implement -> Test -> Review -> Commit<br />
<br />
<div style="padding: 1ex 4em;"><br />
== Administration ==<br />
<br />
{{TodoItem<br />
|Allow administrators to cancel multi-statement idle transactions<br />
|This allows locks to be released, but it is complex to report the cancellation back to the client.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php <nowiki>Cancelling idle in transaction state</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00441.php <nowiki>Re: Cancelling idle in transaction state</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Set proper permissions on non-system schemas during db creation<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow log_min_messages to be specified on a per-module basis<br />
|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]].}}<br />
<br />
{{TodoItem<br />
|Simplify creation of partitioned tables<br />
|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]]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow custom variables to appear in pg_settings()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have custom variables be transaction-safe<br />
* {{MessageLink|4B577E9F.8000505@dunslane.net|Custom GUCs still a bit broken}}<br />
}}<br />
<br />
{{TodoItem<br />
|Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide a way to query the log collector subprocess to determine the name of the currently active log file<br />
* [http://archives.postgresql.org/pgsql-general/2008-11/msg00418.php <nowiki>Current log files when rotating?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow simpler reporting of the unix domain socket directory and allow easier configuration of its default location<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01555.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01482.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow custom daemons to be automatically stopped/started along with the postmaster<br />
|This allows easier administration of daemons like user job schedulers or replication-related daemons.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01701.php <nowiki>Re: scheduler in core</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve logging of prepared transactions recovered during startup<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>&quot;recovering prepared transaction&quot; after server restart message</nowiki>]<br />
}}<br />
<br />
=== Configuration files ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00764.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01509.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-11/msg00002.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider normalizing fractions in postgresql.conf, perhaps using '%'<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow Kerberos to disable stripping of realms so we can check the username@realm against multiple realms<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php <nowiki>krb_match_realm patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve LDAP authentication configuration options<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php <nowiki>Proposed Patch - LDAPS support for servers on port 636 w/o TLS</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add external tool to auto-tune some postgresql.conf parameters<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php <nowiki>Simple postgresql.conf wizard</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php <nowiki>Re: Plans for 8.4</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Process pg_hba.conf keywords as case-insensitive<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00432.php <nowiki>More robust pg_hba.conf parsing/error logging</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Create utility to compute accurate random_page_cost value<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00162.php<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00362.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow configuration files to be independently validated<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php<br />
* http://archives.postgresql.org/message-id/12666.1310774573@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Allow postgresql.conf settings to be accepted by backends even if some settings are invalid for those backends<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow all backends to receive postgresql.conf setting changes at the same time<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow synchronous_standby_names to be disabled after communication failure with all synchronous standby servers exceeds some timeout<br />
|This also requires successful execution of a synchronous notification command.<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00409.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Tablespaces ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|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<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow reporting of which objects are in which tablespaces<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original}}<br />
<br />
{{TodoItem<br />
|Allow per-tablespace quotas}}<br />
<br />
{{TodoItem<br />
|Allow tablespaces on RAM-based partitions for unlogged tables<br />
* http://archives.postgresql.org/pgsql-advocacy/2011-05/msg00033.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow toast tables to be moved to a different tablespace<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-05/msg00980.php]<br />
* {{messageLink|CAFEQCbH756DyyAPQ1ykh3+b+kE1-EhWRww1WO_x5v38C-uLnUg@mail.gmail.com|patch : Allow toast tables to be moved to a different tablespace}} (issues remain)<br />
* [http://archives.postgresql.org/message-id/CAFEQCbEq07OopgE5xFYv2Q3eMq45hRSJkjCBO+kvpJq9NEVhow@mail.gmail.com Allow toast tables to be moved to a different tablespace]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Statistics Collector ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow statistics last vacuum/analyze execution times to be displayed without requiring track_counts to be enabled<br />
* [http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php <nowiki>row-level stats and last analyze time</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Clear table counters on TRUNCATE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php <nowiki>Small TRUNCATE glitch</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== SSL ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow SSL authentication/encryption over unix domain sockets<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00924.php <nowiki>Re: Spoofing as the postmaster</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow SSL key file permission checks to be optionally disabled when sharing SSL keys with other applications<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php <nowiki>BUG #3809: SSL &quot;unsafe&quot; private key permissions bug</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart<br />
|Unlike SSL CRT files, CRL (Certificate Revocation List) files are updated frequently<br />
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00832.php <nowiki>Automatic CRL reload</nowiki>]<br />
Alternatively or additionally supporting OCSP (online certificate security protocol) would provide real-time revocation discovery without reloading<br />
}}<br />
<br />
{{TodoItem<br />
| Allow automatic selection of SSL client certificates from a certificate store<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Send the full certificate server chain to the client<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Point-In-Time Recovery (PITR) ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow archive_mode to be changed without server restart?<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php <nowiki>Enabling archive_mode without restart</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider avoiding WAL switching via archive_timeout if there has been no database activity<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01469.php <nowiki>archive_timeout behavior for no activity</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg00395.php <nowiki>Re: archive_timeout behavior for no activity</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow base backup from standby to continue when the standby is promoted.<br />
* [http://archives.postgresql.org/pgsql-hackers/2012-10/msg00239.php <nowiki>Re: Promoting a standby during base backup</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add recovery target option to stop as soon as consistency is reached.<br />
* [http://archives.postgresql.org/message-id/5188F87D.1080908@vmware.com <nowiki>Re: Recovery target 'immediate'</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Standby server mode ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
| Allow pg_xlogfile_name() to be used in recovery mode<br />
* [http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12@mail.gmail.com <nowiki>Streaming replication and pg_xlogfile_name()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Prevent variables inherited from the server environment from begin used for making streaming replication connections.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01011.php <nowiki>Re: Parameter name standby_mode</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Change walsender so that it applies per-role settings<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00642.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure configuration parameters for standby mode<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01820.php<br />
}}<br />
<br />
{{TodoItemf<br />
| Allow time-delayed application of logs on the standby<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00992.php<br />
}}<br />
<br />
{{TodoItem<br />
| Add -X parameter to pg_basebackup to specify a different directory for px_xlog, like initdb<br />
}}<br />
<br />
{{TodoItem<br />
| Add a new "eager" synchronous mode that starts out synchronous but reverts to asynchronous after a failure timeout period<br />
|This would require some type of command to be executed to alert administrators of this change.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg01224.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Data Types ==<br />
<br />
{{TodoItem<br />
|Fix data types where equality comparison is not intuitive, e.g. box<br />
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01643.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for public SYNONYMs<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php<br />
* http://archives.postgresql.org/pgsql-general/2010-12/msg00139.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for SQL-standard GENERATED/IDENTITY columns<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider placing all sequences in a single table, or create a system view<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2012-02/msg00258.php Removing special case OID generation]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a special data type for regular expressions<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce BIT data type overhead using short varlena headers<br />
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php <nowiki>storage size of &quot;bit&quot; data type..</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow renaming and deleting enumerated values from an existing enumerated data type<br />
}}<br />
<br />
{{TodoItem<br />
|Support scoped IPv6 addresses in the inet type<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php <nowiki>strange problem with ip6</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Considering improving performance of computing CHAR() value lengths<br />
* [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>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01787.php <nowiki>Re: [PATCH] backend: compare word-at-a-time in bcTruelen</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add overlaps geometric operators that ignore point overlaps<br />
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00861.php<br />
}}<br />
<br />
{{TodoItem<br />
|Remove or improve rounding in geometric comparison operators<br />
* http://archives.postgresql.org/message-id/9804.1346187849@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
| Add IMMUTABLE column attribute<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00623.php<br />
}}<br />
<br />
=== Domains ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow functions defined as casts to domains to be called during casting<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow values to be cast to domain types<br />
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>] <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00812.php<br />
}}<br />
<br />
{{TodoItem<br />
|Make domains work better with polymorphic functions<br />
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]<br />
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Dates and Times ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow infinite intervals just like infinite timestamps<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00076.php<br />
}}<br />
<br />
{{TodoItem<br />
|Determine how to represent date/time field extraction on infinite timestamps<br />
* [http://archives.postgresql.org/message-id/CA+mi_8bda-Fnev9iXeUbnqhVaCWzbYhHkWoxPQfBca9eDPpRMw@mail.gmail.com extract(epoch from infinity) is not 0]<br />
* [http://archives.postgresql.org/message-id/CADAkt-icuESH16uLOCXbR-dKpcvwtUJE4JWXnkdAjAAwP6j12g@mail.gmail.com converting between infinity timestamp and float8]<br />
}}<br />
<br />
<br />
{{TodoItem<br />
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC<br />
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules. <br />
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have timestamp subtraction not call justify_hours()?<br />
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve TIMESTAMP WITH TIME ZONE subtraction to be DST-aware<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Fix interval display to support values exceeding 2^31 hours}}<br />
<br />
{{TodoItem<br />
|Add overflow checking to timestamp and interval arithmetic}}<br />
<br />
{{TodoItem<br />
|Add function to allow the creation of timestamps using parameters<br />
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00232.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow a comma to denote fractional seconds in ISO-8601-compliant times (and timestamps)<br />
* http://www.postgresql.org/message-id/7D5AC9AB-238D-4FE7-8857-18D98190A4D9@justatheory.com<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Arrays ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add support for arrays of domains<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php <nowiki>Re: updated WIP: arrays of composites</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow single-byte header storage for array elements}}<br />
<br />
{{TodoItem<br />
|Add function to detect if an array is empty<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php <nowiki>Re: array_length()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of empty arrays<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php <nowiki>So what's an &quot;empty&quot; array anyway?</nowiki>]<br />
* http://archives.postgresql.org/pgsql-general/2012-07/msg00633.php<br />
* [http://www.postgresql.org/message-id/1182.1363387349@sss.pgh.pa.us <nowiki>Allow declaration of an empty array?</nowiki>]<br />
* [http://www.postgresql.org/message-id/CADxJZo0keVhSRzUnot2Y6g46tsP7f-eV28iEmBd3AtLjU-YTMA@mail.gmail.com Exorcise "zero-dimensional" arrays]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of NULLs in arrays<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php <nowiki>BUG #4509: array_cat's null behaviour is inconsistent</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Binary Data ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve vacuum of large objects, like contrib/vacuumlo?}}<br />
<br />
{{TodoItem<br />
|Auto-delete large objects when referencing row is deleted<br />
|contrib/lo offers this functionality.}}<br />
<br />
{{TodoItem<br />
|Allow read/write into TOAST values like large objects<br />
|Writing might require the TOAST column to be stored EXTERNAL.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00049.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== MONEY Data Type ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add locale-aware MONEY type, and support multiple currencies<br />
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Text Search ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow dictionaries to change the token that is passed on to later dictionaries<br />
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Exact phrase search, <br />
* [http://www.sai.msu.su/~megera/wiki/2009-08-12 <nowiki>Algebra for full-text queries</nowiki>]<br />
* [http://www.sai.msu.su/~megera/postgres/talks/2009.pdf <nowiki>Some recent advances in<br />
full-text search</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a function-based API for '@@' searches<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Some recent advances in<br />
full-text search</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve text search error messages<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php <nowiki>Re: Poorly designed tsearch NOTICEs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider changing error to warning for strings larger than one megabyte<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|tsearch and tsdicts regression tests fail in Turkish locale on glibc<br />
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]<br />
}}<br />
<br />
{{TodoItem<br />
|tsquery negator operator treated as part of lexeme<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-06/msg00346.php BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of dash and plus signs in email address user names, and perhaps improve URL parsing<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00772.php<br />
* [http://archives.postgresql.org/message-id/E1Ri8il-0008Ct-9p@wrigleys.postgresql.org tsearch does not recognize all valid emails]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve default parser, to more easily allow adding new tokens<br />
* http://archives.postgresql.org/message-id/23485.1297727826@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Add additional support functions<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00319.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== XML ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow XML arrays to be cast to other data types<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add XML Schema validation and xmlvalidate functions (SQL:2008)}}<br />
<br />
{{TodoItem<br />
|Add xmlvalidatedtd variant to support validating against a DTD?}}<br />
<br />
{{TodoItem<br />
|Relax-NG validation; libxml2 supports this already}}<br />
<br />
{{TodoItem<br />
|Allow reliable XML operation non-UTF8 server encodings (xpath(), in particular, is known to not work)<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php <nowiki>BUG #4622: xpath only work in utf-8 server encoding</nowiki>] <br />
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}<br />
<br />
{{TodoItem<br />
|Add functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}<br />
<br />
{{TodoItem<br />
|Add XMLNAMESPACES support in XMLELEMENT and elsewhere}}<br />
<br />
{{TodoItem<br />
|Move XSLT from contrib/xml2 to a more reasonable location<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00539.php<br />
}}<br />
<br />
{{TodoItem<br />
|Report errors returned by the XSLT library<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00562.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve the XSLT parameter passing API<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00416.php<br />
}}<br />
<br />
{{TodoItem<br />
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}<br />
<br />
{{TodoItem<br />
|Add pretty-printed XML output option<br />
|Parse a document and serialize it back in some indented form. libxml2 might support this.}}<br />
<br />
{{TodoItem<br />
|Add XMLQUERY (from the SQL/XML standard)}}<br />
<br />
{{TodoItem<br />
|Allow XML sthredding<br />
|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.}}<br />
<br />
{{TodoItem<br />
|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]}}<br />
<br />
{{TodoItem<br />
|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]}}<br />
<br />
{{TodoItem<br />
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}<br />
<br />
{{TodoItem<br />
|xpath_table is pretty broken anyway [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php]}}<br />
<br />
{{TodoItem<br />
|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]}}<br />
<br />
{{TodoItem<br />
|Improve handling of PIs and DTDs in xmlconcat() [http://archives.postgresql.org/message-id/200904211211.n3LCB09p008988@wwwmaster.postgresql.org]}}<br />
<br />
{{TodoItem<br />
|Restructure XML and /contrib/xml2 functionality<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02314.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00017.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Functions ==<br />
<br />
{{TodoItem<br />
|Allow INET subnet comparisons using non-constants to be indexed}}<br />
<br />
{{TodoItem<br />
|Add an INET overlaps operator, for use by exclusion constraints <br />
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00845.php<br />
}}<br />
<br />
{{TodoItem<br />
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php <nowiki>RFC for adding typmods to functions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix IS OF so it matches the ISO specification, and add documentation<br />
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement Boyer-Moore searching in LIKE queries<br />
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent malicious functions from being executed with the permissions of unsuspecting users<br />
|Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce memory usage of aggregates in set returning functions<br />
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix /contrib/ltree operator<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix /contrib/btree_gist's implementation of inet indexing<br />
* [http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php <nowiki>BUG #5705: btree_gist: Index on inet changes query result</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|<nowiki>Fix inconsistent precedence of =, &gt;, and &lt; compared to &lt;&gt;, &gt;=, and &lt;=</nowiki><br />
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php <nowiki>BUG #3822: Nonstandard precedence for comparison operators</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix regular expression bug when using complex back-references<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php <nowiki>BUG #3645: regular expression back references seem broken</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have /contrib/dblink reuse unnamed connections<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php <nowiki>dblink un-named connection doesn't get re-used</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve formatting of pg_get_viewdef() output<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01648.php <nowiki>pg_get_viewdef formattiing</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01885.php <nowiki>Re: pretty print viewdefs</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-12/msg00906.php reprise: pretty print viewdefs]<br />
}}<br />
<br />
{{TodoItem<br />
|Add function to dump pg_depend information cleanly<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00226.php <nowiki>Elementary dependency look-up</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add function to allow easier transaction id comparisons<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00786.php<br />
}}<br />
<br />
=== Character Formatting ===<br />
<br />
{{TodoSubsection}}<br />
{{TodoItem<br />
|Allow to_date() and to_timestamp() to accept localized month names}}<br />
<br />
{{TodoItem<br />
|Add missing parameter handling in to_char()<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.<br />
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow to_char() on interval values to accumulate the highest unit requested<br />
|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.<br />
* to_char(INTERVAL '1 hour 5 minutes', 'MI') =&gt; 65<br />
* to_char(INTERVAL '43 hours 20 minutes', 'MI' ) =&gt; 2600<br />
* to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') =&gt; 0:1:19:20<br />
* to_char(INTERVAL '3 years 5 months','MM') =&gt; 41<br />
}}<br />
<br />
{{TodoItem<br />
|Fix to_number() handling for values not matching the format string<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php <nowiki>Re: numeric_to_number() function skipping some digits</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Multi-Language Support ==<br />
<br />
{{TodoItem<br />
|Add NCHAR (as distinguished from ordinary varchar),}}<br />
<br />
{{TodoItem<br />
|Add a cares-about-collation column to pg_proc, so that unresolved-collation errors can be thrown at parse time<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-03/msg01520.php <nowiki>Open issues for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Integrate collations with text search configurations<br />
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Integrate collations with to_char() and related functions<br />
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support collation-sensitive equality and hashing functions<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00472.php <nowiki> contrib/citext versus collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a LOCALE option to CREATE DATABASE, as a shorthand<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support multiple simultaneous character sets, per SQL:2008}}<br />
<br />
{{TodoItem<br />
|Improve UTF8 combined character handling?}}<br />
<br />
{{TodoItem<br />
|Add octet_length_server() and octet_length_client()}}<br />
<br />
{{TodoItem<br />
|Make octet_length_client() the same as octet_length()?}}<br />
<br />
{{TodoItem<br />
|Fix problems with wrong runtime encoding conversion for NLS message files}}<br />
<br />
{{TodoItem<br />
|Add URL to more complete multi-byte regression tests<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-07/msg00272.php <nowiki>Multi-byte and client side character encoding tests for copy command..</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix contrib/fuzzystrmatch to work with multibyte encodings<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00138.php <nowiki> dmetaphone woes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions<br />
|Currently we preallocate memory based on worst-case usage.}}<br />
<br />
{{TodoItem<br />
|Add ability to use case-insensitive regular expressions on multi-byte characters<br />
|Currently it works for UTF-8, but not other multi-byte encodings<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php <nowiki>Regexps vs. locale</nowiki>]<br />
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}<br />
}}<br />
<br />
{{TodoItem<br />
|Improve encoding of connection startup messages sent to the client<br />
|Currently some authentication error messages are sent in the server encoding<br />
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php <nowiki>encoding of PostgreSQL messages</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php <nowiki>Re: encoding of PostgreSQL messages</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|More sensible support for Unicode combining characters, normal forms<br />
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net<br />
}}<br />
<br />
== Views and Rules ==<br />
<br />
{{TodoItemDone<br />
|Add the functionality of the WITH CHECK OPTION clause to CREATE VIEW<br />
}}<br />
{{TodoItem<br />
|Allow VIEW/RULE recompilation when the underlying tables change<br />
|This is both difficult and controversial.<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change2"]<br />
* [http://archives.postgresql.org/message-id/CACk%3DU9NFSzWrEba8G5dZ%3DTZLy3_hx3QXGyCcKVWT%3D4iA1FjMuA@mail.gmail.com VIEW still referring to old name of field]<br />
}}<br />
{{TodoItem<br />
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve ability to modify views via ALTER TABLE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]<br />
}}<br />
<br />
== SQL Commands ==<br />
<br />
{{TodoItem<br />
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT<br />
* [http://dissipatedheat.com/2011/11/10/how-not-to-write-a-patch-for-postgresql/ How not to write this patch.]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve type determination of unknown (NULL or quoted literal) result columns for UNION/INTERSECT/EXCEPT<br />
* [http://archives.postgresql.org/message-id/9799.1302719551@sss.pgh.pa.us <nowiki>UNION construct type cast gives poor error message</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00838.php <nowiki>WIP: grouping sets support</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00466.php <nowiki>Implementation of GROUPING SETS (T431: Extended grouping capabilities)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: &quot;could not open relation 1663/16384/16584: No such file or directory&quot; in a specific combination of transactions with temp tables</nowiki>]<br />
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a GUC variable to warn about non-standard SQL usage in queries}}<br />
<br />
{{TodoItem<br />
|Add SQL-standard MERGE/REPLACE/UPSERT command<br />
|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.<br />
}}<br />
<br />
{{TodoItem<br />
|Add NOVICE output level for helpful messages<br />
|For example, have it warn about unjoined tables. This could also control automatic sequence/index creation messages.<br />
}}<br />
<br />
{{TodoItem<br />
|Allow NOTIFY in rules involving conditionals}}<br />
<br />
{{TodoItem<br />
|Allow EXPLAIN to identify tables that were skipped because of constraint_exclusion<br />
}}<br />
<br />
{{TodoItem<br />
|Simplify dropping roles that have objects in several databases}}<br />
<br />
{{TodoItem<br />
|Allow the count returned by SELECT, etc to be represented as an int64 to allow a higher range of values}}<br />
<br />
{{TodoItem<br />
|Add support for WITH RECURSIVE ... CYCLE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php <nowiki>WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows</nowiki>]}}<br />
<br />
{{TodoItem<br />
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner<br />
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}<br />
<br />
{{TodoItem<br />
|Allow DISTINCT to work in multiple-argument aggregate calls}}<br />
<br />
{{TodoItem<br />
|Add comments on system tables/columns using the information in catalogs.sgml<br />
|Ideally the information would be pulled from the SGML file automatically.}}<br />
<br />
{{TodoItem<br />
|Prevent the specification of conflicting transaction read/write options<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php <nowiki>Re: SET TRANSACTION and SQL Standard</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow DELETE and UPDATE to be used with LIMIT and ORDER BY<br />
* http://archives.postgresql.org/pgadmin-hackers/2010-04/msg00078.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01997.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00021.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow PREPARE of cursors}}<br />
<br />
{{TodoItem<br />
|Have DISCARD PLANS discard plans cached by functions<br />
|DISCARD all should do the same.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00431.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid multiple-evaluation of BETWEEN and IN arguments containing volatile expressions<br />
* http://archives.postgresql.org/message-id/4D95B605.2020709@enterprisedb.com<br />
}}<br />
<br />
{{TodoItem<br />
|Fix nested CASE-WHEN constructs<br />
* http://archives.postgresql.org/message-id/4DDCEEB8.50602@enterprisedb.com<br />
}}<br />
<br />
=== CREATE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}<br />
<br />
{{TodoItem<br />
|Have WITH CONSTRAINTS also create constraint indexes<br />
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Move NOT NULL constraint information to pg_constraint<br />
|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?)<br />
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us<br />
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg01223.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00358.php<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add CREATE SCHEMA ... LIKE that copies a schema}}<br />
<br />
{{TodoItem<br />
|Fix CREATE OR REPLACE FUNCTION to not leave objects depending on the function in inconsistent state<br />
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow temporary tables to exist as empty by default in all sessions<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php <nowiki>idea: global temp tables</nowiki>]<br />
* [http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php <nowiki>Re: idea: global temp tables</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg01098.php <nowiki>global temporary tables</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2012-04/msg01148.php Temporary tables under hot standby]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the creation of "distinct" types<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php <nowiki>Distinct types</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider analyzing temporary tables when they are first used in a query<br />
|Autovacuum cannot analyze or vacuum temporary tables.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php <nowiki>autovacuum and temp tables support</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow an unlogged table to be changed to logged<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00437.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00323.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00237.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== UPDATE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|<nowiki>Allow UPDATE tab SET ROW (col, ...) = (SELECT...)</nowiki><br />
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg01308.php <nowiki>Re: [PATCHES] extension for sql update</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00865.php <nowiki>UPDATE using sub selects</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php <nowiki>UPDATE using sub selects</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php <nowiki>Re: UPDATE using sub selects</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00016.php <nowiki>Re: Do we need a TODO? (was Re: Concurrently updating anupdatable view)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows<br />
|This is related to the previous item, which questions whether it even has the right semantics<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ALTER ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Have ALTER TABLE RENAME of a SERIAL column rename the sequence<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CADLWmXUV4LbLhMZL8rYMhCy72aZZLB5BSARPQVgoX0BrxA0FFg@mail.gmail.com renaming implicit sequences]<br />
}}<br />
<br />
{{TodoItem<br />
|Have ALTER SEQUENCE RENAME rename the sequence name stored in the sequence table<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-09/msg00092.php <nowiki>BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00007.php <nowiki>Re: BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add ALTER DOMAIN to modify the underlying data type}}<br />
<br />
{{TodoItem<br />
|Allow ALTER TABLESPACE to move the tablespace to different directories}}<br />
<br />
{{TodoItem<br />
|Allow moving system tables to other tablespaces, where possible<br />
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}<br />
<br />
{{TodoItem<br />
|Have ALTER INDEX update the name of a constraint using that index}}<br />
<br />
{{TodoItem<br />
|Allow column display reordering by recording a display, storage, and permanent id for every column?<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php <nowiki>Column reordering in pg_dump</nowiki>]<br />
* http://archives.postgresql.org/message-id/1324412114-sup-9608@alvh.no-ip.org<br />
}}<br />
<br />
{{TodoItem<br />
|Allow deactivating (and reactivating) indexes via ALTER TABLE<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01191.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add ALTER OPERATOR ... RENAME<br />
|needs to consider effects of changing operator precedence<br />
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== CLUSTER ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Automatically maintain clustering on a table<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]<br />
* http://community.enterprisedb.com/git/<br />
* [http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php <nowiki>Re: maintain_cluster_order_v5.patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Allow CLUSTER to be used on a partial index<br />
* http://www.postgresql.org/message-id/CAMkU%3D1zYwoHHsqJ8wfK3GdG_t_a6t4RK-GFDSKymQ0EGP%3DtypA@mail.gmail.com<br />
}} <br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== COPY ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow COPY to report error lines and continue<br />
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure. <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY FROM to create index entries in bulk<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY in CSV mode to control whether a quoted zero-length string is treated as NULL<br />
|Currently this is always treated as a zero-length string, which generates an error when loading into an integer column <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php <nowiki>Re: [PATCHES] allow CSV quote in NULL</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve COPY performance<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01882.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY to report errors sooner<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY to handle other number formats<br />
|E.g. the German notation. Best would be something like WITH DECIMAL ','.<br />
}}<br />
<br />
{{TodoItem<br />
|Allow a stalled COPY to exit if the backend is terminated<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00067.php <nowiki>Re: possible bug not in open items</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== GRANT/REVOKE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow SERIAL sequences to inherit permissions from the base table?}}<br />
<br />
{{TodoItem<br />
|Allow dropping of a role that has connection rights<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php <nowiki>DROP ROLE dependency tracking ...</nowiki>]<br />
}}<br />
{{TodoEndSubsection}}<br />
<br />
=== DECLARE CURSOR ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}<br />
<br />
{{TodoItem<br />
|Provide some guarantees about the behavior of cursors that invoke volatile functions<br />
* [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]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== INSERT ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow INSERT/UPDATE of the system-generated oid value for a row}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== SHOW/SET ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}<br />
<br />
{{TodoItem<br />
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count<br />
* [http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php <nowiki>Re: [ADMIN] shared_buffers and shmmax</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ANALYZE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}<br />
<br />
{{TodoItem<br />
|Have EXPLAIN ANALYZE report rows as floating-point numbers<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg01363.php <nowiki>explain analyze rows=%.0f</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00108.php <nowiki>Re: explain analyze rows=%.0f</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve how ANALYZE computes in-doubt tuples<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Window Functions ===<br />
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.<br />
{{TodoSubsection}}<br />
{{TodoItem<br />
|Support creation of user-defined window functions<br />
|We have the ability to create new window functions written in C. Is it<br />
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}<br />
<br />
{{TodoItem<br />
|Implement full support for window framing clauses<br />
|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.<br />
* RANGE BETWEEN ... PRECEDING/FOLLOWING<br />
* EXCLUDE<br />
}}<br />
<br />
{{TodoItem<br />
|Investigate tuplestore performance issues<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php <nowiki>tuplestore potential performance problem</nowiki>]<br />
}}<br />
<br />
{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}<br />
<br />
{{TodoItem<br />
|Teach planner to evaluate multiple windows in the optimal order<br />
|Currently windows are always evaluated in the query-specified order.<br />
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64<br />
}}<br />
<br />
{{TodoItem<br />
|Implement DISTINCT clause in window aggregates<br />
|Some proprietary RDBMSs have implemented it already, so it helps with porting from those.}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Integrity Constraints ==<br />
=== Keys ===<br />
<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve deferrable unique constraints for cases with many conflicts<br />
|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.<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Referential Integrity ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add MATCH PARTIAL referential integrity}}<br />
<br />
{{TodoItem<br />
|Change foreign key constraint for array -&gt; element to mean element in array?<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-10/msg01814.php <nowiki>foreign keys for array/period contains relationships</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Are ri_KeysEqual checks in the RI enforcement triggers still necessary?<br />
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Check Constraints ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Run check constraints only when affected columns are changed<br />
* http://archives.postgresql.org/message-id/1326055327.15293.13.camel@vanquo.pezone.net<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Server-Side Languages ==<br />
<br />
{{TodoItem<br />
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}<br />
<br />
{{TodoItem<br />
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}<br />
<br />
{{TodoItem<br />
|Add more fine-grained specification of functions taking arbitrary data types<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php <nowiki>RfD: more powerful &quot;any&quot; types</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement stored procedures<br />
|This might involve the control of transaction state and the return of multiple result sets<br />
* [http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php <nowiki>PL/pgSQL stored procedure returning multiple result sets (SELECTs)?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php <nowiki>Gathering specs and discussion on feature (post 9.1)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow holdable cursors in SPI}}<br />
<br />
=== SQL-Language Functions ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Rethink query plan caching and timing of parse analysis within SQL-language functions<br />
|They should work more like plpgsql functions do ...<br />
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00078.php <nowiki>Re: BUG #6019: invalid cached plan on inherited table</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/pgSQL ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}<br />
<br />
{{TodoItem<br />
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki><br />
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow row and record variables to be set to NULL constants, and allow NULL tests on such variables<br />
|Because a row is not scalar, do not allow assignment from NULL-valued scalars.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider keeping separate cached copies when search_path changes<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of NULL row values vs. NULL rows<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php <nowiki>Null row vs. row of nulls in plpgsql</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01973.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve PERFORM handling of WITH queries or document limitation<br />
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00309.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/Perl ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow regex operations in plperl using UTF8 characters in non-UTF8 encoded databases}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/Python ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Develop a trusted variant of PL/Python.}}<br />
<br />
{{TodoItem<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-02/msg01468.php <nowiki>Re: pl/python do not delete function arguments</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a DB-API compliant interface on top of the SPI interface<br />
* http://petereisentraut.blogspot.com/2011/11/plpydbapi-db-api-for-plpython.html<br />
}}<br />
<br />
{{TodoItem<br />
|For functions returning a setof record with a composite type, cache the I/O functions for the composite type<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02007.php<br />
}}<br />
<br />
{{TodoItemDone<br />
|Fix loss of information during conversion of numeric type to Python float}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/Tcl ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add table function support}}<br />
<br />
{{TodoItem<br />
|Check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, and SPI calls.}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Clients ==<br />
<br />
{{TodoItem<br />
|Add a function like pg_get_indexdef() that report more detailed index information<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Split out pg_resetxlog output into pre- and post-sections<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php<br />
}}<br />
<br />
=== pg_ctl ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve pg_ctl's detection of running postmasters<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00000.php<br />
* http://archives.postgresql.org/pgsql-committers/2011-06/msg00001.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add additional shutdown modes, and change the default?<br />
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg01283.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== psql ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Have psql \ds show all sequences and their settings<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00916.php <nowiki>Re: TODO item: Have psql show current values for a sequence</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00401.php <nowiki>Quick patch: Display sequence owner</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Move psql backslash database information into the backend, use mnemonic commands?<br />
|This would allow non-psql clients to pull the same information out of the database as psql. <br />
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Make psql's \d commands more consistent in their handling of schemas<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php <nowiki>Re: psql and schemas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Make psql's \d commands distinguish default privileges from no privileges<br />
|ACL displays were visibly different for the two cases before we "improved" them by using array_to_string.<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consistently display privilege information for all objects in psql}}<br />
<br />
{{TodoItemEasy<br />
|\s without arguments (display history) fails with libedit, doesn't use pager either<br />
* [http://archives.postgresql.org/pgsql-bugs/2011-06/msg00114.php <nowiki> psql \s not working - OS X</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a \set variable to control whether \s displays line numbers<br />
|Another option is to add \# which lists line numbers, and allows command execution.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Include the symbolic SQLSTATE name in verbose error reports<br />
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add prompt escape to display the client and server versions<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.<br />
|Currently, &quot;wrapped&quot; format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]<br />
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}<br />
<br />
{{TodoItem<br />
|Support the ReST table output format<br />
|Details about the ReST format: http://docutils.sourceforge.net/rst.html#reference-documentation<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg01007.php <nowiki>Proposal: new border setting in psql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00518.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00609.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add option to print advice for people familiar with other databases<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php <nowiki>MySQL-ism help patch for psql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add ability to edit views with \ev<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00023.php <nowiki>Adding \ev view editor?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php<br />
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent psql from sending remaining single-line multi-statement queries after reconnecting<br />
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php<br />
}}<br />
<br />
{{TodoItemEasy<br />
|Add \i option to bring in the specified file as a quoted literal<br />
|This would be useful for creating functions and other areas. Details still need to be worked out.<br />
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00016.php<br />
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00020.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having psql -c read .psqlrc, for consistency<br />
|psql -f already reads .psqlrc<br />
}}<br />
<br />
{{TodoItem<br />
|Allow processing of multiple -f (file) options<br />
* http://www.postgresql.org/message-id/AANLkTikFpzrTRl6392GhatQdwlCWQTXFdSMxh5CP51iv@mail.gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Improve line drawing characters<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00386.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider improving the continuation prompt<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01772.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve speed of tab completion by using LIKE<br />
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== pg_dump / pg_restore ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItemEasy<br />
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}<br />
<br />
{{TodoItemEasy<br />
|Modify pg_dump to create skeleton views for reload (which are then updated via CREATE OR REPLACE VIEW) when views have circular dependencies. This should eliminate the need for the CREATE RULE "_RETURN" hack currently used to address this issue. Thread and additional information here:<br />
* [http://www.postgresql.org/message-id/25554.1360895028@sss.pgh.pa.us Description of change]<br />
|}}<br />
<br />
{{TodoItem<br />
|Add pg_dumpall custom format dumps?<br />
* [http://archives.postgresql.org/pgsql-general/2010-05/msg00509.php pg_dumpall custom format]<br />
|}}<br />
<br />
{{TodoItem<br />
|Avoid using platform-dependent locale names in pg_dumpall output<br />
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get<br />
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.<br />
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Allow selection of individual object(s) of all types, not just tables}}<br />
<br />
{{TodoItem<br />
|In a selective dump, allow dumping of an object and all its dependencies}}<br />
<br />
{{TodoItem<br />
|Add options like pg_restore -l and -L to pg_dump}}<br />
<br />
{{TodoItem<br />
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}<br />
<br />
{{TodoItem<br />
|Allow pg_dump --clean to drop roles that own objects or have privileges<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}<br />
<br />
{{TodoItem<br />
|Remove support for dumping from pre-7.3 servers<br />
|In 7.3 and later, we can get accurate dependency information from the server. pg_dump still contains a lot of crufty code<br />
to try to deal with the lack of dependency info in older servers, but the usefulness of maintaining that code grows small.}}<br />
<br />
{{TodoItem<br />
|Refactor handling of database attributes between pg_dump and pg_dumpall<br />
|Currently only pg_dumpall emits database attributes, such as ALTER DATABASE SET commands and database-level GRANTs.<br />
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,<br />
but it's unclear whether that will satisfy the demand.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2010-05/msg00010.php summary of the issues]<br />
}}<br />
<br />
{{TodoItem<br />
|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.<br />
|This will require new backend syntax, perhaps COMMENT ON CURRENT DATABASE. This is related to the previous item.}}<br />
<br />
{{TodoItem<br />
|Allow parallel restore of tar dumps<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-02/msg01154.php <nowiki>Re: parallel restore</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Preserve sparse storage of large objects over dump/restore<br />
* [http://archives.postgresql.org/message-id/18789.1349750451@sss.pgh.pa.us <nowiki>TODO item: teach pg_dump about sparsely-stored large objects</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ecpg ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Docs<br />
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}<br />
<br />
{{TodoItem<br />
|Solve cardinality &gt; 1 for input descriptors / variables?}}<br />
<br />
{{TodoItem<br />
|Add a semantic check level, e.g. check if a table really exists}}<br />
<br />
{{TodoItem<br />
|fix handling of DB attributes that are arrays}}<br />
<br />
{{TodoItem<br />
|Fix nested C comments}}<br />
<br />
{{TodoItemEasy<br />
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}<br />
<br />
{{TodoItem<br />
|Make SET CONNECTION thread-aware, non-standard?}}<br />
<br />
{{TodoItem<br />
|Allow multidimensional arrays}}<br />
<br />
{{TodoItem<br />
|Implement COPY FROM STDIN}} <br />
<br />
{{TodoItem<br />
|Provide a way to specify size of a bytea parameter<br />
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]<br />
}}<br />
<br />
{{TodoItemEasy<br />
|Fix small memory leaks in ecpg<br />
|Memory leaks in a short running application like ecpg are not really a problem, but make debugging more complicated}} <br />
<br />
{{TodoItem<br />
|Allow reuse of cursor name variables<br />
* [http://archives.postgresql.org/message-id/20100329113435.GA3430@feivel.credativ.lan <nowiki>Problems with variable cursorname in ecpg</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== libpq ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Prevent PQfnumber() from lowercasing unquoted column names<br />
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}<br />
<br />
{{TodoItem<br />
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add PQexecf() that allows complex parameter substitution<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add SQLSTATE and severity to errors generated within libpq itself<br />
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01425.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for interface/ipaddress binding to libpq<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php <nowiki>SR/libpq - outbound interface/ipaddress binding</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== HTTP===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow access to the database via HTTP<br />
|See [[HTTP_API]]}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Triggers ==<br />
<br />
{{TodoItem<br />
|Improve storage of deferred trigger queue<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php <nowiki>Scaling up deferred unique checks and the after trigger queue</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00023.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow triggers to be disabled in only the current session.<br />
|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.}}<br />
<br />
{{TodoItem<br />
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY<br />
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}<br />
<br />
{{TodoItem<br />
|Allow statement-level triggers to access modified rows}}<br />
<br />
{{TodoItem<br />
|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<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php <nowiki>Statement-level triggers and inheritance</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Tighten trigger permission checks<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow BEFORE INSERT triggers on views<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add database and transaction-level triggers<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce locking requirements for creating a trigger<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php <nowiki>Re: Change lock requirements for adding a trigger</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid requirement for "AFTER" trigger functions to return a value<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02384.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow creation of inline triggers<br />
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00708.php<br />
}}<br />
<br />
== Inheritance ==<br />
<br />
{{TodoItem<br />
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-05/msg00285.php <nowiki>Partitioning/inherited tables vs FKs</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00039.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00305.php<br />
}}<br />
<br />
{{TodoItem<br />
|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<br />
|The main difficulty with this item is the problem of creating an index that can span multiple tables.}}<br />
<br />
{{TodoItem<br />
|Determine whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY). If yes, implement it.}}<br />
<br />
{{TodoItem<br />
|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.}}<br />
<br />
== Indexes ==<br />
<br />
{{TodoItem<br />
|Prevent index uniqueness checks when UPDATE does not modify the column<br />
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.<br />
However, HOT already short-circuits this in common cases, so more work might not be helpful.<br />
* http://www.postgresql.org/message-id/CA+TgmoZOyaTanfEvNUdiHBCuu9Zh0JVP1e_UTVbx6Rvj9vFC9Q@mail.gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php <nowiki>Bitmap Indexes: request for feedback</nowiki>]<br />
* http://archives.postgresql.org/message-id/800923.27831.qm@web29010.mail.ird.yahoo.com <br />
}}<br />
<br />
{{TodoItem<br />
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics<br />
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02179.php <br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00459.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02054.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01731.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00894.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00679.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having a larger statistics target for indexed columns and expression indexes. <br />
}}<br />
<br />
{{TodoItem<br />
|Consider smaller indexes that record a range of values per heap page, rather than having one index entry for every heap row<br />
|This is useful if the heap is clustered by the indexed values. <br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00341.php <nowiki>Grouped Index Tuples</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01264.php <nowiki>Grouped Index Tuples</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00465.php <nowiki>Grouped Index Tuples / Clustered Indexes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php <nowiki>Bitmapscan changes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php <nowiki>Re: GIT patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php <nowiki>Re: Index Tuple Compression Approach?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php <nowiki>Re: Index AM change proposals, redux</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00911.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg00128.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multiple indexes to be created concurrently, ideally via a single heap scan<br />
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.<br />
Cluster could definitely benefit from this.<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00093.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider sorting entries before inserting into btree index<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow creation of an index that can do comparisons to test if a value is between two column values<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00757.php <nowiki>Proposal: temporal extension &quot;period&quot; data type</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider using "effective_io_concurrency" for index scans<br />
|Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.<br />
* [http://www.postgresql.org/message-id/CAGTBQpZzf70n0PYJ%3DVQLd+jb3wJGo%3D2TXmY+SkJD6G_vjC5QNg@mail.gmail.com Prefetch index pages for B-Tree index scans]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix problem with btree page splits during checkpoints<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00052.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00184.php<br />
}}<br />
<br />
{{TodoItem<br />
|[http://archives.postgresql.org/pgsql-hackers/2012-05/msg00669.php Support amgettuple() in GIN (useful for exclusion constraints)]<br />
}}<br />
<br />
{{TodoItem<br />
| Allow "loose" or "skip" scans on btree indexes in which the first column has low cardinality<br />
* http://archives.postgresql.org/pgsql-performance/2012-08/msg00159.php<br />
}}<br />
<br />
{{TodoItem<br />
| Make the planner's "special index operator" mechanism extensible<br />
* http://www.postgresql.org/message-id/27270.1364700924@sss.pgh.pa.us<br />
}}<br />
<br />
<br />
=== GIST ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add more GIST index support for geometric data types}}<br />
<br />
{{TodoItem<br />
|Allow GIST indexes to create certain complex index types, like digital trees (see Aoki)}}<br />
<br />
{{TodoItem<br />
|Fix performance issues in contrib/seg and contrib/cube GiST support<br />
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]<br />
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]<br />
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00069.php <nowiki>Re: GiST index performance</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-performance/2009-06/msg00068.php <nowiki>GiST index performance</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|[http://archives.postgresql.org/message-id/4DC8D284-05CF-4E3D-9670-AC9A32C37A36@justatheory.com GiST index support for arrays]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Hash ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add UNIQUE capability to hash indexes}}<br />
<br />
{{TodoItem<br />
|Add hash WAL logging for crash recovery<br />
* http://archives.postgresql.org/pgsql-performance/2011-09/msg00196.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multi-column hash indexes}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Sorting ==<br />
<br />
{{TodoItem<br />
|Consider whether duplicate keys should be sorted by block/offset<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider being smarter about memory and external files used during sorts<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php <nowiki>Re: Sorting Improvements for 8.4</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider detoasting keys before sorting}}<br />
<br />
{{TodoItemDone<br />
|Allow sorts to use more available memory<br />
* http://archives.postgresql.org/pgsql-hackers/2007-11/msg01026.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01123.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg01957.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow sorts of skinny tuples to use even more available memory.<br />
* Now that it is not limited by MaxAllocSize, don't limit by INT_MAX either.<br />
* http://www.postgresql.org/message-id/CA+U5nMKkRMin1pV8VMpS6_n7hcOWSG0kZS3oFL9JOa8DV6vJyQ@mail.gmail.com<br />
}}<br />
<br />
== Fsync ==<br />
<br />
{{TodoItem<br />
|Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether fsync does anything<br />
|Ideally this requires a separate test program like /contrib/pg_test_fsync that can be run at initdb time or optionally later.<br />
}}<br />
<br />
{{TodoItem<br />
|Consider sorting writes during checkpoint<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php <nowiki>Re: Sorting writes during checkpoint</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg02012.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00278.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00493.php<br />
}}<br />
<br />
== Cache Usage ==<br />
<br />
{{TodoItem<br />
|Provide a way to calculate an &quot;estimated COUNT(*)&quot;<br />
|Perhaps by using the optimizer's cardinality estimates or random sampling.<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php <nowiki>Re: Improving count(*)</nowiki>]<br />
* http://wiki.postgresql.org/wiki/Slow_Counting<br />
}}<br />
<br />
{{TodoItem<br />
|Consider automatic caching of statements at various levels:<br />
* Parsed query tree<br />
* Query execute plan<br />
* Query results <br />
<br />
:<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider increasing internal areas (NUM_CLOG_BUFFERS) when shared buffers is increased<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php <nowiki>Re: slru.c race condition (was Re: TRAP: FailedAssertion(&quot;!((itemid)-&gt;lp_flags &amp; 0x01)&quot;,)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php <nowiki>clog_buffers to 64 in 8.3?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php <nowiki>CLOG Patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider decreasing the amount of memory used by PrivateRefCount<br />
|<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php <nowiki>PrivateRefCount (for 8.3)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php <nowiki>Re: PrivateRefCount (for 8.3)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider allowing higher priority queries to have referenced buffer cache pages stay in memory longer<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve cache lookup speed for sessions accessing many relations<br />
* http://archives.postgresql.org/pgsql-hackers/2012-11/msg00356.php<br />
}}<br />
<br />
== Vacuum ==<br />
<br />
{{TodoItem<br />
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow concurrent inserts to use recently created pages rather than creating new ones<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having single-page pruning update the visibility map<br />
* <nowiki>https://commitfest.postgresql.org/action/patch_view?id=75</nowiki><br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php <nowiki>Re: visibility maps and heap_prune</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]<br />
}}<br />
<br />
{{TodoItem<br />
|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<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php <nowiki>FSM search modes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a more compact data representation for dead tuple locations within VACUUM<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide more information in order to improve user-side estimates of dead space bloat in relations<br />
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve locking behaviour of vacuum during trailing page truncation<br />
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00319.php<br />
* http://archives.postgresql.org/message-id/4D8DF88E.7080205@Yahoo.com<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce the number of table scans performed by vacuum<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00605.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php<br />
}}<br />
<br />
{{TodoItem<br />
|Vacuum Gin indexes in physically order rather than logical order<br />
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg00443.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid creation of the free space map for small tables<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg01751.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00552.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00615.php<br />
}}<br />
<br />
=== Auto-vacuum ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItemEasy<br />
|Issue log message to suggest VACUUM FULL if a table is nearly empty?}}<br />
<br />
{{TodoItem<br />
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation<br />
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can do that. <br />
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent autovacuum from running if an old transaction is still running from the last vacuum<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have autoanalyze of parent tables occur when child tables are modified<br />
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php<br />
* http://archives.postgresql.org/pgsql-performance/2010-10/msg00271.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow visibility map all-visible bits to be set even when an auto-ANALYZE is running<br />
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00356.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow parallel cores to be used by vacuumdb<br />
* [http://archives.postgresql.org/message-id/4F10A728.7090403@agliodbs.com vacuumdb -j]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve autovacuum tuning<br />
* http://www.postgresql.org/message-id/5078AD6B.8060802@agliodbs.com<br />
* http://www.postgresql.org/message-id/20130124215715.GE4528@alvh.no-ip.org<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Locking ==<br />
<br />
{{TodoItem<br />
|Fix priority ordering of read and write light-weight locks<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php <nowiki>lwlocks and starvation</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php <nowiki>Re: lwlocks and starvation</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow UPDATEs on only non-referential integrity columns not to conflict with referential integrity locks<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php <nowiki>Referential Integrity and SHARE locks</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add idle_in_transaction_timeout GUC so locks are not held for long periods of time}}<br />
<br />
{{TodoItem<br />
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Detect deadlocks involving LockBufferForCleanup()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow finer control over who is cancelled in a deadlock<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01727.php<br />
}}<br />
<br />
== Startup Time Improvements ==<br />
<br />
{{TodoItem<br />
|Experiment with multi-threaded backend for backend creation<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow backends to change their database without restart<br />
|This allows for faster server startup.<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00843.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00336.php<br />
}}<br />
<br />
== Write-Ahead Log ==<br />
<br />
{{TodoItem<br />
|Eliminate need to write full pages to WAL before page modification<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01191.php<br />
* [http://archives.postgresql.org/message-id/20120105061916.GB21048@fetter.org WIP double writes]<br />
* [http://archives.postgresql.org/message-id/4EFC449F02000025000441CD@gw.wicourts.gov double writes]<br />
* [http://archives.postgresql.org/message-id/20120110214344.GB21106@fetter.org Double-write with Fast Checksums]<br />
* [http://archives.postgresql.org/message-id/1962493974.656458.1327703514780.JavaMail.root@zimbra-prod-mbox-4.vmware.com double writes using "double-write buffer" approach]<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01463.php<br />
}}<br />
<br />
{{TodoItem<br />
|When full page writes are off, write CRC to WAL and check file system blocks on recovery<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Write full pages during file system write and not when the page is modified in the buffer cache<br />
|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.<br />
* [http://archives.postgresql.org/message-id/CAGvK12UST-tPhyLrSLuSpwFxZbAO79yYrhV2xaLmS2MkUxNUVQ@mail.gmail.com Page Checksums + Double Writes]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce WAL traffic so only modified values are written rather than entire rows<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php <nowiki>Reduction in WAL for UPDATEs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow WAL information to recover corrupted pg_controldata<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Find a way to reduce rotational delay when repeatedly writing last WAL page<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php <nowiki>500 tpsQL + WAL log implementation</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Speed WAL recovery by allowing more than one page to be prefetched<br />
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay. <br />
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve WAL concurrency by increasing lock granularity<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Be more aggressive about creating WAL files<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php <nowiki>Re: PANIC caused by open_sync on Linux</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-07/msg01075.php <nowiki>PreallocXlogFiles</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-04/msg00556.php <nowiki>WAL/PITR additional items</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have resource managers report the duration of their status changes<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Close deleted WAL files held open in *nix by long-lived read-only backends<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]<br />
}}<br />
<br />
== Optimizer / Executor ==<br />
<br />
{{TodoItem<br />
|Improve selectivity functions for geometric operators}}<br />
<br />
{{TodoItem<br />
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold<br />
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00597.php<br />
}}<br />
<br />
{{TodoItem<br />
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}<br />
<br />
{{TodoItem<br />
|Consider compressed annealing to search for query plans<br />
|This might replace GEQO.<br />
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Improve use of expression indexes for ORDER BY <br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php <nowiki>Resjunk sort columns, Heikki's index-only quals patch, and bug #5000</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Modify the planner to better estimate caching effects<br />
* http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow shared buffer cache contents to affect index cost computations<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the CTE (Common Table Expression) optimization fence to be optionally disabled<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00700.php<br />
* http://archives.postgresql.org/pgsql-performance/2012-11/msg00161.php<br />
}}<br />
<br />
=== Hashing ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Consider using a hash for joining to a large IN (VALUES ...) list<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow single batch hash joins to preserve outer pathkeys<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|"lazy" hash tables - look up only the tuples that are actually requested<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid building the same hash table more than once during the same query<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid hashing for distinct and then re-hashing for hash join<br />
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Background Writer ==<br />
<br />
{{TodoItem<br />
|Consider having the background writer update the transaction status hint bits before writing out the page<br />
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.}}<br />
<br />
{{TodoItem<br />
|Consider adding buffers the background writer finds reusable to the free list <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]<br />
}}<br />
<br />
{{TodoItem<br />
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency<br />
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]<br />
}}<br />
<br />
== Concurrent Use of Resources ==<br />
<br />
{{TodoItem<br />
|Do async I/O for faster random read-ahead of data<br />
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]<br />
* [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>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]<br />
* [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>]<br />
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.<br />
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]<br />
}}<br />
<br />
{{TodoItem<br />
|Experiment with multi-threaded backend for better I/O utilization<br />
|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.<br />
* http://archives.postgresql.org/pgsql-performance/2011-02/msg00123.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01139.php<br />
}}<br />
<br />
{{TodoItem<br />
|Experiment with multi-threaded backend for better CPU utilization<br />
|This would allow several CPUs to be used for a single query, such as for sorting or query execution.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00945.php <nowiki>Multi CPU Queries - Feedback and/or suggestions wanted!</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|SMP scalability improvements<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]<br />
}}<br />
<br />
== TOAST ==<br />
<br />
{{TodoItem<br />
|Allow user configuration of TOAST thresholds<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce unnecessary cases of deTOASTing<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce costs of repeat de-TOASTing of values<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]<br />
}}<br />
<br />
== Monitoring ==<br />
{{TodoItem<br />
|Expand pg_stat_activity for easier integration with monitoring tools<br />
|* http://archives.postgresql.org/message-id/4DFA13A5.2060200@2ndQuadrant.com<br />
}}<br />
<br />
{{TodoItem<br />
|Add column to pg_stat_activity that shows the progress of long-running commands like CREATE INDEX and VACUUM<br />
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00203.php <nowiki>EXPLAIN progress info</nowiki>]<br />
* The CLUSTER/VACUUM FULL implementation would also be useful to track this way<br />
}}<br />
<br />
{{TodoItem<br />
|Have pg_stat_activity display query strings in the correct client encoding<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php <nowiki>pg_stats queries versus per-database encodings</nowiki>]<br />
}}<br />
<br />
{{TodoItemEasy<br />
|Expose pg_controldata via an SQL interface<br />
|Helpful for monitoring replicated databases<br />
* http://archives.postgresql.org/message-id/4B901D73.8030003@agliodbs.com<br />
* [http://archives.postgresql.org/message-id/4B959D7A.6010907@joeconway.com initial patch]<br />
}}<br />
<br />
{{TodoItem<br />
| Add entry creation timestamp column to pg_stat_replication<br />
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00694.php<br />
}}<br />
<br />
{{TodoItem<br />
| Allow reporting of stalls due to wal_buffer wrap-around<br />
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00826.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure pg_stat_database columns tup_returned and tup_fetched to return meaningful values<br />
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org<br />
}}<br />
<br />
== Miscellaneous Performance ==<br />
<br />
{{TodoItem<br />
|Use mmap() rather than shared memory for shared buffers?<br />
|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.<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00750.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00756.php<br />
}}<br />
<br />
{{TodoItem<br />
|Rather than consider mmap()-ing in 8k pages, consider mmap()'ing entire files into a backend?<br />
|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.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01239.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider ways of storing rows more compactly on disk:<br />
* Reduce the row header size?<br />
* Consider reducing on-disk varlena length from four bytes to two because a heap row cannot be more than 64k in length}}<br />
<br />
{{TodoItem<br />
|Consider transaction start/end performance improvements<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php <nowiki>Reducing Transaction Start/End Contention</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow configuration of backend priorities via the operating system<br />
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.<br />
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider increasing the minimum allowed number of shared buffers<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call<br />
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation<br />
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Sort large UPDATE/DELETEs so it is done in heap order<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider decreasing the I/O caused by updating tuple hint bits<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid the requirement of freezing pages that are infrequently modified <br />
|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<br />
* http://archives.postgresql.org/message-id/4BF701CF.2090205@agliodbs.com<br />
* http://archives.postgresql.org/pgsql-hackers/2010-06/msg00082.php<br />
* http://www.postgresql.org/message-id/20130523175148.GA29374@alap2.anarazel.de<br />
* http://www.postgresql.org/message-id/CA+TgmoaEmnoLZmVbb8gvY69NA8zw9BWpiZ9+TLz-LnaBOZi7JA@mail.gmail.com<br />
* http://www.postgresql.org/message-id/51A7553E.5070601@vmware.com<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode<br />
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Restructure truncation logic to be more resistant to failure<br />
|This also involves not writing dirty buffers for a truncated or dropped relation<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider adding logic to increase large tables by more than 8k<br />
|This would reduce file system fragmentation<br />
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00337.php<br />
}}<br />
<br />
== Miscellaneous Other ==<br />
<br />
{{TodoItem<br />
|Deal with encoding issues for filenames in the server filesystem<br />
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}<br />
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}<br />
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}<br />
}}<br />
<br />
{{TodoItem<br />
|Deal with encoding issues in the output of localeconv()<br />
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]<br />
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]<br />
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports<br />
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]<br />
* [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>]<br />
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add 64-bit support to /contrib/pgbench<br />
* http://archives.postgresql.org/pgsql-hackers/2010-07/msg00153.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00705.php<br />
}}<br />
<br />
== Source Code ==<br />
<br />
{{TodoItemEasy<br />
|Remove warnings created by -Wcast-align}}<br />
<br />
{{TodoItem<br />
|Move platform-specific ps status display info from ps_status.c to ports}}<br />
<br />
{{TodoItem<br />
|Consider a faster CRC32 algorithm<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow cross-compiling by generating the zic database on the target system}}<br />
<br />
{{TodoItem<br />
|Improve NLS maintenance of libpgport messages linked onto applications}}<br />
<br />
{{TodoItem<br />
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}<br />
<br />
{{TodoItem<br />
|Allow creation of universal binaries for Darwin<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider GnuTLS if OpenSSL license becomes a problem<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php<br />
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider making NAMEDATALEN more configurable in future releases}}<br />
<br />
{{TodoItem<br />
|Research use of signals and sleep wake ups<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow C++ code to more easily access backend code<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider simplifying how memory context resets handle child contexts<br />
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Create three versions of libpgport to simplify client code<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement the non-threaded Avahi service discovery protocol<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce data row alignment requirements on some 64-bit systems<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Restructure TOAST internal storage format for greater flexibility<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Add regression tests for pg_dump/restore<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01967.php <nowiki>"make install-check-pg_dump" target in src/regress]</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Research different memory allocation methods for lists<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php <br />
}}<br />
<br />
{{TodoItem<br />
| Consider removing the attribute options cache<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00039.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure /contrib section<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00705.php<br />
}}<br />
<br />
{{TodoItem<br />
| Consider adding explicit huge page support<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00123.php<br />
}}<br />
<br />
=== /contrib/pg_upgrade ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Handle large object comments<br />
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.<br />
}}<br />
<br />
{{TodoItem<br />
|Consider using pg_depend for checking object usage in version.c<br />
}}<br />
<br />
{{TodoItem<br />
|If reindex is necessary, allow it to be done in parallel with pg_dump custom format<br />
}}<br />
<br />
{{TodoItem<br />
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary<br />
|pg_class.oid is not preserved so schema.tablename must be used.<br />
* [http://archives.postgresql.org/message-id/CAAZKuFaWdLkK8eozSAooZBets9y_mfo2HS6urPAKXEPbd-JLCA@mail.gmail.com pg_upgrade and statistics]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve testing, perhaps using the buildfarm<br />
|The buildfarm has access to multiple versions of PostgreSQL.<br />
}}<br />
<br />
{{TodoItem<br />
|Create machine-readable output of pg_controldata<br />
|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.<br />
}}<br />
<br />
{{TodoItem<br />
|Find cleaner way to start/stop dedicated servers for upgrades<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00275.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a way to run pg_upgrade on standby servers<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00453.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00056.php<br />
}}<br />
<br />
{{TodoItem<br />
|Desired changes that would prevent upgrades with pg_upgrade<br />
* 32-bit page checksums<br />
* Add metapage to GiST indexes<br />
* Clean up hstore's internal representation<br />
* Remove tuple infomask bit HEAP_MOVED_OFF and HEAP_MOVED_IN<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Windows ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Remove configure.in check for link failure when cause is found}}<br />
<br />
{{TodoItem<br />
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}<br />
<br />
{{TodoItem<br />
|Allow psql to use readline once non-US code pages work with backslashes}}<br />
<br />
{{TodoItem<br />
|Fix problem with shared memory on the Win32 Terminal Server}}<br />
<br />
{{TodoItem<br />
|Improve signal handling<br />
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Convert MSVC build system to remove most batch files<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support pgxs when using MSVC}}<br />
<br />
{{TodoItem<br />
|Fix MSVC NLS support, like for to_char()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Find a correct rint() substitute on Windows<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix global namespace issues when using multiple terminal server sessions<br />
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}<br />
<br />
{{TodoItem<br />
|Change from the current autoconf/gmake build system to cmake<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve consistency of path separator usage<br />
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net<br />
}}<br />
<br />
{{TodoItem<br />
|Fix cross-compiling on Windows<br />
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce file statistics overhead on directory reads<br />
* http://www.postgresql.org/message-id/1338325561.82125.YahooMailNeo@web39304.mail.mud.yahoo.com<br />
}}<br />
<br />
<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Wire Protocol Changes ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow dynamic character set handling}}<br />
<br />
{{TodoItem<br />
|Let the client indicate character encoding of database names, user names, and passwords<br />
* http://www.postgresql.org/message-id/16160.1360540050@sss.pgh.pa.us}}<br />
<br />
{{TodoItem<br />
|Add decoded type, length, precision}}<br />
<br />
{{TodoItem<br />
|Mark result columns as known-not-null when possible<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide more control over planner treatment of statements being prepared}}<br />
<br />
{{TodoItem<br />
|Use compression<br />
|If SSL is used, hopefully avoid the overhead of key negotiation and encryption<br />
* http://archives.postgresql.org/pgsql-hackers/2012-06/msg00793.php<br />
}}<br />
<br />
{{TodoItem<br />
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}<br />
<br />
{{TodoItem<br />
|Set protocol for wire format negotiation<br />
* [http://archives.postgresql.org/message-id/CACMqXCKkGrGXxQhjHCKCe0B8hn6sTt-1sdgHZOSGQMxrusOsQA@mail.gmail.com GUC_REPORT for protocol tunables]<br />
}}<br />
<br />
{{TodoItem<br />
|Make sure upgrading to a 4.1 protocol version will actually work smoothly<br />
* [http://archives.postgresql.org/message-id/28307.1318255008@sss.pgh.pa.us Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multi-state authentication<br />
* http://www.postgresql.org/message-id/51A44185.5060306@2ndquadrant.com<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Documentation ==<br />
<br />
{{TodoItemEasy <br />
| Add contrib functions to the index<br />
* Add the functions and GUCs in the contrib modules to [http://www.postgresql.org/docs/current/static/sql-createindex.html the documentation index]: [http://archives.postgresql.org/message-id/50A2E173.6030404@2ndQuadrant.com per list discussion]<br />
}}<br />
<br />
{{TodoItem<br />
|Convert single quotes to apostrophes in the PDF documentation<br />
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide a manpage for postgresql.conf<br />
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}<br />
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}<br />
}}<br />
<br />
{{TodoItem<br />
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools<br />
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}<br />
}}<br />
<br />
{{TodoItem<br />
|Consider changing documentation format from SGML to XML<br />
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]<br />
* http://archives.postgresql.org/pgsql-docs/2011-04/msg00020.php<br />
* http://wiki.postgresql.org/wiki/Switching_PostgreSQL_documentation_from_SGML_to_XML<br />
}}<br />
<br />
{{TodoItem<br />
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard<br />
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com<br />
}}<br />
<br />
{{TodoItem<br />
|Add diagrams to the documentation<br />
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php<br />
}}<br />
<br />
== Exotic Features ==<br />
<br />
{{TodoItem<br />
|Add pre-parsing phase that converts non-ISO syntax to supported syntax<br />
|This could allow SQL written for other databases to run without modification.}}<br />
<br />
{{TodoItem<br />
|Allow plug-in modules to emulate features from other databases}}<br />
<br />
{{TodoItem<br />
|Add features of Oracle-style packages<br />
|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 &quot;packages&quot; syntax at all.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider allowing control of upper/lower case folding of unquoted identifiers<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]<br />
* [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>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add autonomous transactions<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Give query progress indication<br />
* [[Query progress indication]]<br />
}}<br />
<br />
{{TodoItem<br />
|Rethink our type system<br />
* [[Rethinking datatypes]]<br />
}}<br />
<br />
== Features We Do ''Not'' Want ==<br />
<br />
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.<br />
<br />
{{TodoItem<br />
|All backends running as threads in a single process (not wanted)<br />
|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.}}<br />
<br />
{{TodoItem<br />
|"Oracle-style" optimizer hints (not wanted)<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Embedded server (not wanted)<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Obfuscated function source code (not wanted)<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Indeterminate behavior for the GROUP BY clause (not wanted)<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]<br />
}}<br />
<br />
</div><br />
<br />
[[Category:Todo]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=Pg_gethostname&diff=19408Pg gethostname2013-04-24T00:31:13Z<p>Theory: Add PGXN link.</p>
<hr />
<div>{{SnippetInfo|C function to get server hostname |version=9.0+|lang=C|category=Library}}<br />
<br />
Here is a compilable C function to get the server hostname. An updated version is also available [http://pgxn.org/dist/hostname/ on PGXN].<br />
<br />
Tested with CentOS 5 x86_64, postgresql 9.0 & 9.1.<br />
<br />
Probably works in earlier versions of pg and other linux distros, but haven't tested.<br />
<br />
<source lang="C"><br />
/*<br />
A PostgreSQL function for getting the hostname.<br />
<br />
File: `pg_config --libdir`/pg_gethostname.c<br />
<br />
To compile... (make sure pg_config is in your PATH)<br />
gcc -I$(pg_config --includedir-server) -fpic -c pg_gethostname.c -L$(pg_config --libdir)<br />
gcc --shared -o pg_gethostname.so pg_gethostname.o<br />
<br />
To create the funciton in PostgreSQL...<br />
CREATE OR REPLACE FUNCTION pg_gethostname() RETURNS text<br />
AS 'pg_gethostname'<br />
LANGUAGE C IMMUTABLE STRICT;<br />
<br />
*/<br />
#include "postgres.h"<br />
#include <limits.h><br />
#include <unistd.h><br />
#include <string.h><br />
#include "fmgr.h"<br />
<br />
#include "utils/palloc.h"<br />
#include "utils/elog.h"<br />
#include "storage/bufpage.h"<br />
<br />
#ifdef PG_MODULE_MAGIC<br />
PG_MODULE_MAGIC;<br />
#endif<br />
<br />
<br />
PG_FUNCTION_INFO_V1( pg_gethostname );<br />
<br />
Datum pg_gethostname( PG_FUNCTION_ARGS );<br />
<br />
Datum pg_gethostname( PG_FUNCTION_ARGS )<br />
{<br />
text *t;<br />
char server_hostname[HOST_NAME_MAX];<br />
size_t length;<br />
<br />
if ( gethostname( server_hostname, HOST_NAME_MAX ) != 0 )<br />
{<br />
// returning an empty string for the hostname if it fails makes<br />
// sense because if it succeeded, we would have a name<br />
server_hostname[0] = '\0';<br />
}<br />
<br />
length = strnlen( server_hostname, HOST_NAME_MAX );<br />
t = (text *) palloc(VARHDRSZ + length );<br />
SET_VARSIZE( t, VARHDRSZ + length );<br />
memcpy( VARDATA(t), server_hostname, length );<br />
<br />
PG_RETURN_TEXT_P( t );<br />
}<br />
<br />
</source><br />
<br />
Usage:<br />
<br />
postgres# select pg_gethostname();<br />
pg_gethostname <br />
----------------<br />
myserver<br />
<br />
<br />
[[Category:C]]<br />
<br />
<br />
'''Installation with a makefile'''<br />
<br />
http://www.postgresql.org/docs/9.1/static/extend-pgxs.html<br />
<br />
This worked for me on Ubuntu 12.04 64bit PostgreSQL 9.1<br />
<br />
Create a makefile in the directory of your choice<br />
<br />
# makefile<br />
MODULES = pg_gethostname<br />
<br />
PG_CONFIG = pg_config<br />
PGXS := $(shell $(PG_CONFIG) --pgxs)<br />
include $(PGXS)<br />
<br />
Put pg_gethostname.c in the same directory and run the following script.<br />
You have to have pg_config in your path<br />
<br />
#!/bin/bash<br />
# Install script<br />
PGXS=`pg_config --pgxs`<br />
PG_CONFIG=`which pg_config`<br />
make<br />
make install<br />
echo "CREATE OR REPLACE FUNCTION pg_gethostname() RETURNS text AS 'pg_gethostname' LANGUAGE C IMMUTABLE STRICT;" | psql -U postgres template1</div>Theoryhttps://wiki.postgresql.org/index.php?title=PgCon2013CanadaClusterSummit&diff=19389PgCon2013CanadaClusterSummit2013-04-17T16:20:37Z<p>Theory: restore header</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2013 = <br />
<br />
Tuesday, May 21st<br />
<br />
9:30AM to 2:30pm<br />
<br />
Followed by PostgresXC Summit 3pm to 6pm<br />
<br />
University of Ottawa<br />
<br />
Room TBD<br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 9AM to 9:30AM ====<br />
<br />
Seating and coffee. Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 9:30AM to 10:15AM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates:<br />
<br />
* pgPoolII: Tatsuo Ishii<br />
* Postgres-XC: Koichi Suzuki<br />
* Built-in Replication: Simon Riggs<br />
* Stado: Mason Sharp<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 17.<br />
<br />
==== 10:15AM to 10:30 AM ====<br />
<br />
Break<br />
<br />
==== 10:30AM to 11:30AM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* Event Triggers: <br />
* Exportable Snapshots:<br />
* <br />
<br />
==== 11:30AM to 12:30PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
==== 12:30PM to 1:30PM ====<br />
<br />
Lunch and follow-up discussion. Box lunches will be supplied.<br />
<br />
==== 1:30PM to 2:30PM ====<br />
<br />
Follow-up discussion. Consolidation of future clustering API goals and projects.<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Kevin Grittner<br />
# Jim Mlodgenski<br />
# Mason Sharp<br />
# Nikhil Sontakke<br />
# Steve Singer<br />
# Jan Wieck<br />
# David Wheeler<br />
# Ashutosh Bapat<br />
<br />
= PostgresXC Day =<br />
<br />
=== 3pm to 6pm ===<br />
<br />
Same room as clustering summit.<br />
<br />
* Topics in Version 1.1<br />
* Roadmap toward version 1.2 and beyond<br />
* Development Issues<br />
* Experiences<br />
<br />
=== Extension on Wednesday and Saturday ===<br />
<br />
Informal open discussion on Postgres-XC feature and internal will be held at Koichi's hotel room on 22nd, Wednesday. Depending upon topics, similar discussion can be held on Saturday.<br />
<br />
=== RSVP List ===<br />
<br />
Please check if you can join. Add yourself in the list too.<br />
<br />
# Ahsan Hadi<br />
# Ashutosh Bapat<br />
# Hitoshi Hemmi<br />
# Koichi Suzuki<br />
# Tetsuo Sakata<br />
<br />
[[Category:PostgreSQL Events]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PgCon2013CanadaClusterSummit&diff=19388PgCon2013CanadaClusterSummit2013-04-17T16:19:11Z<p>Theory: Oh, two RSVP lists, my mistake.</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2013 = <br />
<br />
Tuesday, May 21st<br />
<br />
9:30AM to 2:30pm<br />
<br />
Followed by PostgresXC Summit 3pm to 6pm<br />
<br />
University of Ottawa<br />
<br />
Room TBD<br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 9AM to 9:30AM ====<br />
<br />
Seating and coffee. Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 9:30AM to 10:15AM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates:<br />
<br />
* pgPoolII: Tatsuo Ishii<br />
* Postgres-XC: Koichi Suzuki<br />
* Built-in Replication: Simon Riggs<br />
* Stado: Mason Sharp<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 17.<br />
<br />
==== 10:15AM to 10:30 AM ====<br />
<br />
Break<br />
<br />
==== 10:30AM to 11:30AM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* Event Triggers: <br />
* Exportable Snapshots:<br />
* <br />
<br />
==== 11:30AM to 12:30PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
==== 12:30PM to 1:30PM ====<br />
<br />
Lunch and follow-up discussion. Box lunches will be supplied.<br />
<br />
==== 1:30PM to 2:30PM ====<br />
<br />
Follow-up discussion. Consolidation of future clustering API goals and projects.<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Kevin Grittner<br />
# Jim Mlodgenski<br />
# Mason Sharp<br />
# Nikhil Sontakke<br />
# Steve Singer<br />
# Jan Wieck<br />
# David Wheeler<br />
# Ashutosh Bapat<br />
<br />
= PostgresXC Day =<br />
<br />
=== 3pm to 6pm ===<br />
<br />
Same room as clustering summit.<br />
<br />
* Topics in Version 1.1<br />
* Roadmap toward version 1.2 and beyond<br />
* Development Issues<br />
* Experiences<br />
<br />
=== Extension on Wednesday and Saturday ===<br />
<br />
Informal open discussion on Postgres-XC feature and internal will be held at Koichi's hotel room on 22nd, Wednesday. Depending upon topics, similar discussion can be held on Saturday.<br />
<br />
=== RSVP List ===<br />
<br />
Please check if you can join. Add yourself in the list too.<br />
<br />
# Ahsan Hadi<br />
# Ashutosh Bapat<br />
# Hitoshi Hemmi<br />
# Koichi Suzuki<br />
# Tetsuo Sakata<br />
<br />
[[Category:PostgreSQL Events]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PgCon2013CanadaClusterSummit&diff=19387PgCon2013CanadaClusterSummit2013-04-17T16:18:10Z<p>Theory: /* RSVP List */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2013 = <br />
<br />
Tuesday, May 21st<br />
<br />
9:30AM to 2:30pm<br />
<br />
Followed by PostgresXC Summit 3pm to 6pm<br />
<br />
University of Ottawa<br />
<br />
Room TBD<br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 9AM to 9:30AM ====<br />
<br />
Seating and coffee. Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 9:30AM to 10:15AM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates:<br />
<br />
* pgPoolII: Tatsuo Ishii<br />
* Postgres-XC: Koichi Suzuki<br />
* Built-in Replication: Simon Riggs<br />
* Stado: Mason Sharp<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 17.<br />
<br />
==== 10:15AM to 10:30 AM ====<br />
<br />
Break<br />
<br />
==== 10:30AM to 11:30AM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* Event Triggers: <br />
* Exportable Snapshots:<br />
* <br />
<br />
==== 11:30AM to 12:30PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
==== 12:30PM to 1:30PM ====<br />
<br />
Lunch and follow-up discussion. Box lunches will be supplied.<br />
<br />
==== 1:30PM to 2:30PM ====<br />
<br />
Follow-up discussion. Consolidation of future clustering API goals and projects.<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Kevin Grittner<br />
# Jim Mlodgenski<br />
# Mason Sharp<br />
# Nikhil Sontakke<br />
# Steve Singer<br />
# Jan Wieck<br />
# David Wheeler<br />
# Ashutosh Bapat<br />
<br />
= PostgresXC Day =<br />
<br />
=== 3pm to 6pm ===<br />
<br />
Same room as clustering summit.<br />
<br />
* Topics in Version 1.1<br />
* Roadmap toward version 1.2 and beyond<br />
* Development Issues<br />
* Experiences<br />
<br />
=== Extension on Wednesday and Saturday ===<br />
<br />
Informal open discussion on Postgres-XC feature and internal will be held at Koichi's hotel room on 22nd, Wednesday. Depending upon topics, similar discussion can be held on Saturday.<br />
<br />
=== RSVP List ===<br />
<br />
Please check if you can join. Add yourself in the list too.<br />
<br />
# Ahsan Hadi<br />
# Ashutosh Bapat<br />
# Hitoshi Hemmi<br />
# Koichi Suzuki<br />
# Tetsuo Sakata<br />
# David E. Wheeler<br />
<br />
[[Category:PostgreSQL Events]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PgCon2013CanadaClusterSummit&diff=19310PgCon2013CanadaClusterSummit2013-04-02T17:47:11Z<p>Theory: /* RSVP List */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2013 = <br />
<br />
Tuesday, May 21st<br />
<br />
9:30AM to 2:30pm<br />
<br />
Followed by PostgresXC Summit 3pm to 6pm<br />
<br />
University of Ottawa<br />
<br />
Room TBD<br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 9AM to 9:30AM ====<br />
<br />
Seating and coffee. Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 9:30AM to 10:15AM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates:<br />
<br />
* pgPoolII: Tatsuo Ishii<br />
* Postgres-XC: Koichi Suzuki<br />
* Built-in Replication: Simon Riggs<br />
* Stado: Mason Sharp<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 17.<br />
<br />
==== 10:15AM to 10:30 AM ====<br />
<br />
Break<br />
<br />
==== 10:30AM to 11:30AM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* Event Triggers: <br />
* Exportable Snapshots:<br />
* <br />
<br />
==== 11:30AM to 12:30PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
==== 12:30PM to 1:30PM ====<br />
<br />
Lunch and follow-up discussion. Box lunches will be supplied.<br />
<br />
==== 1:30PM to 2:30PM ====<br />
<br />
Follow-up discussion. Consolidation of future clustering API goals and projects.<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Kevin Grittner<br />
# Jim Mlodgenski<br />
# Mason Sharp<br />
# Nikhil Sontakke<br />
# Steve Singer<br />
# Jan Wieck<br />
# David Wheeler<br />
<br />
= PostgresXC Summit =<br />
<br />
3pm to 6pm<br />
<br />
Same room as clustering summit.<br />
<br />
Agenda TBD.<br />
<br />
<br />
[[Category:PostgreSQL Events]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=Todo&diff=19253Todo2013-03-15T23:03:55Z<p>Theory: Link to discussion on initializing an empty array.</p>
<hr />
<div><div style="margin: 1ex 1em; float: right;"><br />
__TOC__<br />
</div><br />
<br />
This list contains '''known PostgreSQL bugs and feature requests''' and we hope it is complete. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].<br />
<br />
* {{TodoPending}} - marks ordinary, incomplete items<br />
* {{TodoEasy}} - marks items that are easier to implement<br />
* {{TodoDone}} - marks changes that are done, and will appear in the PostgreSQL 9.3 release.<br />
<br />
For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the mailing list.</b><br />
<br />
<b>For Developers:</b> 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:<br />
<br />
Desirability -> Design -> Implement -> Test -> Review -> Commit<br />
<br />
<div style="padding: 1ex 4em;"><br />
== Administration ==<br />
<br />
{{TodoItem<br />
|Allow administrators to cancel multi-statement idle transactions<br />
|This allows locks to be released, but it is complex to report the cancellation back to the client.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php <nowiki>Cancelling idle in transaction state</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00441.php <nowiki>Re: Cancelling idle in transaction state</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Set proper permissions on non-system schemas during db creation<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow log_min_messages to be specified on a per-module basis<br />
|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]].}}<br />
<br />
{{TodoItem<br />
|Simplify creation of partitioned tables<br />
|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]]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow custom variables to appear in pg_settings()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have custom variables be transaction-safe<br />
* {{MessageLink|4B577E9F.8000505@dunslane.net|Custom GUCs still a bit broken}}<br />
}}<br />
<br />
{{TodoItem<br />
|Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide a way to query the log collector subprocess to determine the name of the currently active log file<br />
* [http://archives.postgresql.org/pgsql-general/2008-11/msg00418.php <nowiki>Current log files when rotating?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow simpler reporting of the unix domain socket directory and allow easier configuration of its default location<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01555.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01482.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow custom daemons to be automatically stopped/started along with the postmaster<br />
|This allows easier administration of daemons like user job schedulers or replication-related daemons.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01701.php <nowiki>Re: scheduler in core</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve logging of prepared transactions recovered during startup<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>&quot;recovering prepared transaction&quot; after server restart message</nowiki>]<br />
}}<br />
<br />
{{TodoItemDone<br />
|Consider using POSIX shared memory to avoid System V shared memory kernel limits<br />
* [http://archives.postgresql.org/message-id/4DFA2673.3010009@enterprisedb.com <nowiki>POSIX shared memory patch status</nowiki>]<br />
}}<br />
<br />
=== Configuration files ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItemDone<br />
|Change pg_ident.conf parsing to be the same as pg_hba.conf<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg02204.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00764.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01509.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-11/msg00002.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider normalizing fractions in postgresql.conf, perhaps using '%'<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow Kerberos to disable stripping of realms so we can check the username@realm against multiple realms<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php <nowiki>krb_match_realm patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve LDAP authentication configuration options<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php <nowiki>Proposed Patch - LDAPS support for servers on port 636 w/o TLS</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add external tool to auto-tune some postgresql.conf parameters<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php <nowiki>Simple postgresql.conf wizard</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php <nowiki>Re: Plans for 8.4</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Process pg_hba.conf keywords as case-insensitive<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00432.php <nowiki>More robust pg_hba.conf parsing/error logging</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Create utility to compute accurate random_page_cost value<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00162.php<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00362.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow configuration files to be independently validated<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php<br />
* http://archives.postgresql.org/message-id/12666.1310774573@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Allow postgresql.conf settings to be accepted by backends even if some settings are invalid for those backends<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow all backends to receive postgresql.conf setting changes at the same time<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow synchronous_standby_names to be disabled after communication failure with all synchronous standby servers exceeds some timeout<br />
|This also requires successful execution of a synchronous notification command.<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00409.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Tablespaces ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|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<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow reporting of which objects are in which tablespaces<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original}}<br />
<br />
{{TodoItem<br />
|Allow per-tablespace quotas}}<br />
<br />
{{TodoItem<br />
|Allow tablespaces on RAM-based partitions for unlogged tables<br />
* http://archives.postgresql.org/pgsql-advocacy/2011-05/msg00033.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow toast tables to be moved to a different tablespace<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-05/msg00980.php]<br />
* {{messageLink|CAFEQCbH756DyyAPQ1ykh3+b+kE1-EhWRww1WO_x5v38C-uLnUg@mail.gmail.com|patch : Allow toast tables to be moved to a different tablespace}} (issues remain)<br />
* [http://archives.postgresql.org/message-id/CAFEQCbEq07OopgE5xFYv2Q3eMq45hRSJkjCBO+kvpJq9NEVhow@mail.gmail.com Allow toast tables to be moved to a different tablespace]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Statistics Collector ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow statistics last vacuum/analyze execution times to be displayed without requiring track_counts to be enabled<br />
* [http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php <nowiki>row-level stats and last analyze time</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Clear table counters on TRUNCATE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php <nowiki>Small TRUNCATE glitch</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== SSL ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow SSL authentication/encryption over unix domain sockets<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00924.php <nowiki>Re: Spoofing as the postmaster</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow SSL key file permission checks to be optionally disabled when sharing SSL keys with other applications<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php <nowiki>BUG #3809: SSL &quot;unsafe&quot; private key permissions bug</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart<br />
|Unlike SSL CRT files, CRL (Certificate Revocation List) files are updated frequently<br />
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00832.php <nowiki>Automatic CRL reload</nowiki>]<br />
Alternatively or additionally supporting OCSP (online certificate security protocol) would provide real-time revocation discovery without reloading<br />
}}<br />
<br />
{{TodoItem<br />
| Allow automatic selection of SSL client certificates from a certificate store<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Send the full certificate server chain to the client<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Point-In-Time Recovery (PITR) ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItemDone<br />
|Create dump tool for write-ahead logs for use in determining transaction id for point-in-time recovery<br />
|This is useful for checking PITR recovery.}}<br />
<br />
{{TodoItem<br />
|Allow archive_mode to be changed without server restart?<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php <nowiki>Enabling archive_mode without restart</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider avoiding WAL switching via archive_timeout if there has been no database activity<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01469.php <nowiki>archive_timeout behavior for no activity</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg00395.php <nowiki>Re: archive_timeout behavior for no activity</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow base backup from standby to continue when the standby is promoted.<br />
* [http://archives.postgresql.org/pgsql-hackers/2012-10/msg00239.php <nowiki>Re: Promoting a standby during base backup</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Standby server mode ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
| Allow pg_xlogfile_name() to be used in recovery mode<br />
* [http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12@mail.gmail.com <nowiki>Streaming replication and pg_xlogfile_name()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Prevent variables inherited from the server environment from begin used for making streaming replication connections.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01011.php <nowiki>Re: Parameter name standby_mode</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Change walsender so that it applies per-role settings<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00642.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure configuration parameters for standby mode<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01820.php<br />
}}<br />
<br />
{{TodoItemf<br />
| Allow time-delayed application of logs on the standby<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00992.php<br />
}}<br />
<br />
{{TodoItem<br />
| Add -X parameter to pg_basebackup to specify a different directory for px_xlog, like initdb<br />
}}<br />
<br />
{{TodoItem<br />
| Add a new "eager" synchronous mode that starts out synchronous but reverts to asynchronous after a failure timeout period<br />
|This would require some type of command to be executed to alert administrators of this change.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg01224.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Data Types ==<br />
<br />
{{TodoItem<br />
|Fix data types where equality comparison is not intuitive, e.g. box<br />
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01643.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for public SYNONYMs<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php<br />
* http://archives.postgresql.org/pgsql-general/2010-12/msg00139.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for SQL-standard GENERATED/IDENTITY columns<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider placing all sequences in a single table, or create a system view<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2012-02/msg00258.php Removing special case OID generation]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a special data type for regular expressions<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce BIT data type overhead using short varlena headers<br />
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php <nowiki>storage size of &quot;bit&quot; data type..</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow renaming and deleting enumerated values from an existing enumerated data type<br />
}}<br />
<br />
{{TodoItem<br />
|Support scoped IPv6 addresses in the inet type<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php <nowiki>strange problem with ip6</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Considering improving performance of computing CHAR() value lengths<br />
* [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>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01787.php <nowiki>Re: [PATCH] backend: compare word-at-a-time in bcTruelen</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add overlaps geometric operators that ignore point overlaps<br />
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00861.php<br />
}}<br />
<br />
{{TodoItem<br />
|Remove or improve rounding in geometric comparison operators<br />
* http://archives.postgresql.org/message-id/9804.1346187849@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
| Add IMMUTABLE column attribute<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00623.php<br />
}}<br />
<br />
=== Domains ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow functions defined as casts to domains to be called during casting<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow values to be cast to domain types<br />
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>] <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00812.php<br />
}}<br />
<br />
{{TodoItem<br />
|Make domains work better with polymorphic functions<br />
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]<br />
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Dates and Times ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow infinite intervals just like infinite timestamps<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00076.php<br />
}}<br />
<br />
{{TodoItem<br />
|Determine how to represent date/time field extraction on infinite timestamps<br />
* [http://archives.postgresql.org/message-id/CA+mi_8bda-Fnev9iXeUbnqhVaCWzbYhHkWoxPQfBca9eDPpRMw@mail.gmail.com extract(epoch from infinity) is not 0]<br />
* [http://archives.postgresql.org/message-id/CADAkt-icuESH16uLOCXbR-dKpcvwtUJE4JWXnkdAjAAwP6j12g@mail.gmail.com converting between infinity timestamp and float8]<br />
}}<br />
<br />
<br />
{{TodoItem<br />
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC<br />
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules. <br />
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have timestamp subtraction not call justify_hours()?<br />
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve TIMESTAMP WITH TIME ZONE subtraction to be DST-aware<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Fix interval display to support values exceeding 2^31 hours}}<br />
<br />
{{TodoItem<br />
|Add overflow checking to timestamp and interval arithmetic}}<br />
<br />
{{TodoItem<br />
|Add function to allow the creation of timestamps using parameters<br />
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00232.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Arrays ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add support for arrays of domains<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php <nowiki>Re: updated WIP: arrays of composites</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow single-byte header storage for array elements}}<br />
<br />
{{TodoItem<br />
|Add function to detect if an array is empty<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php <nowiki>Re: array_length()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of empty arrays<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php <nowiki>So what's an &quot;empty&quot; array anyway?</nowiki>]<br />
* http://archives.postgresql.org/pgsql-general/2012-07/msg00633.php<br />
* [http://www.postgresql.org/message-id/1182.1363387349@sss.pgh.pa.us <nowiki>Allow declaration of an empty array?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of NULLs in arrays<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php <nowiki>BUG #4509: array_cat's null behaviour is inconsistent</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Binary Data ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve vacuum of large objects, like contrib/vacuumlo?}}<br />
<br />
{{TodoItem<br />
|Auto-delete large objects when referencing row is deleted<br />
|contrib/lo offers this functionality.}}<br />
<br />
{{TodoItem<br />
|Allow read/write into TOAST values like large objects<br />
|Writing might require the TOAST column to be stored EXTERNAL.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00049.php<br />
}}<br />
<br />
{{TodoItemDone<br />
|Add API for 64-bit large object access<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00781.php <nowiki>64-bit API for large objects</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01790.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== MONEY Data Type ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add locale-aware MONEY type, and support multiple currencies<br />
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Text Search ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow dictionaries to change the token that is passed on to later dictionaries<br />
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a function-based API for '@@' searches<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Simplifying Text Search</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve text search error messages<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php <nowiki>Re: Poorly designed tsearch NOTICEs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider changing error to warning for strings larger than one megabyte<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|tsearch and tsdicts regression tests fail in Turkish locale on glibc<br />
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]<br />
}}<br />
<br />
{{TodoItem<br />
|tsquery negator operator treated as part of lexeme<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-06/msg00346.php BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of dash and plus signs in email address user names, and perhaps improve URL parsing<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00772.php<br />
* [http://archives.postgresql.org/message-id/E1Ri8il-0008Ct-9p@wrigleys.postgresql.org tsearch does not recognize all valid emails]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve default parser, to more easily allow adding new tokens<br />
* http://archives.postgresql.org/message-id/23485.1297727826@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Add additional support functions<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00319.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== XML ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow XML arrays to be cast to other data types<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add XML Schema validation and xmlvalidate functions (SQL:2008)}}<br />
<br />
{{TodoItem<br />
|Add xmlvalidatedtd variant to support validating against a DTD?}}<br />
<br />
{{TodoItem<br />
|Relax-NG validation; libxml2 supports this already}}<br />
<br />
{{TodoItem<br />
|Allow reliable XML operation non-UTF8 server encodings (xpath(), in particular, is known to not work)<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php <nowiki>BUG #4622: xpath only work in utf-8 server encoding</nowiki>] <br />
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}<br />
<br />
{{TodoItem<br />
|Add functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}<br />
<br />
{{TodoItem<br />
|Add XMLNAMESPACES support in XMLELEMENT and elsewhere}}<br />
<br />
{{TodoItem<br />
|Move XSLT from contrib/xml2 to a more reasonable location<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00539.php<br />
}}<br />
<br />
{{TodoItem<br />
|Report errors returned by the XSLT library<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00562.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve the XSLT parameter passing API<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00416.php<br />
}}<br />
<br />
{{TodoItem<br />
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}<br />
<br />
{{TodoItem<br />
|Add pretty-printed XML output option<br />
|Parse a document and serialize it back in some indented form. libxml2 might support this.}}<br />
<br />
{{TodoItem<br />
|Add XMLQUERY (from the SQL/XML standard)}}<br />
<br />
{{TodoItem<br />
|Allow XML sthredding<br />
|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.}}<br />
<br />
{{TodoItem<br />
|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]}}<br />
<br />
{{TodoItem<br />
|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]}}<br />
<br />
{{TodoItem<br />
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}<br />
<br />
{{TodoItem<br />
|xpath_table is pretty broken anyway [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php]}}<br />
<br />
{{TodoItem<br />
|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]}}<br />
<br />
{{TodoItem<br />
|Improve handling of PIs and DTDs in xmlconcat() [http://archives.postgresql.org/message-id/200904211211.n3LCB09p008988@wwwmaster.postgresql.org]}}<br />
<br />
{{TodoItem<br />
|Restructure XML and /contrib/xml2 functionality<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02314.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00017.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Functions ==<br />
<br />
{{TodoItem<br />
|Allow INET subnet comparisons using non-constants to be indexed}}<br />
<br />
{{TodoItem<br />
|Add an INET overlaps operator, for use by exclusion constraints <br />
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00845.php<br />
}}<br />
<br />
{{TodoItem<br />
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php <nowiki>RFC for adding typmods to functions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix IS OF so it matches the ISO specification, and add documentation<br />
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement Boyer-Moore searching in LIKE queries<br />
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent malicious functions from being executed with the permissions of unsuspecting users<br />
|Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce memory usage of aggregates in set returning functions<br />
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix /contrib/ltree operator<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix /contrib/btree_gist's implementation of inet indexing<br />
* [http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php <nowiki>BUG #5705: btree_gist: Index on inet changes query result</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|<nowiki>Fix inconsistent precedence of =, &gt;, and &lt; compared to &lt;&gt;, &gt;=, and &lt;=</nowiki><br />
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php <nowiki>BUG #3822: Nonstandard precedence for comparison operators</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix regular expression bug when using complex back-references<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php <nowiki>BUG #3645: regular expression back references seem broken</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have /contrib/dblink reuse unnamed connections<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php <nowiki>dblink un-named connection doesn't get re-used</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve formatting of pg_get_viewdef() output<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01648.php <nowiki>pg_get_viewdef formattiing</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01885.php <nowiki>Re: pretty print viewdefs</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-12/msg00906.php reprise: pretty print viewdefs]<br />
}}<br />
<br />
{{TodoItem<br />
|Add function to dump pg_depend information cleanly<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00226.php <nowiki>Elementary dependency look-up</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add function to allow easier transaction id comparisons<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00786.php<br />
}}<br />
<br />
=== Character Formatting ===<br />
<br />
{{TodoSubsection}}<br />
{{TodoItem<br />
|Allow to_date() and to_timestamp() to accept localized month names}}<br />
<br />
{{TodoItem<br />
|Add missing parameter handling in to_char()<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.<br />
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow to_char() on interval values to accumulate the highest unit requested<br />
|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.<br />
* to_char(INTERVAL '1 hour 5 minutes', 'MI') =&gt; 65<br />
* to_char(INTERVAL '43 hours 20 minutes', 'MI' ) =&gt; 2600<br />
* to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') =&gt; 0:1:19:20<br />
* to_char(INTERVAL '3 years 5 months','MM') =&gt; 41<br />
}}<br />
<br />
{{TodoItem<br />
|Fix to_number() handling for values not matching the format string<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php <nowiki>Re: numeric_to_number() function skipping some digits</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Multi-Language Support ==<br />
<br />
{{TodoItem<br />
|Add NCHAR (as distinguished from ordinary varchar),}}<br />
<br />
{{TodoItem<br />
|Add a cares-about-collation column to pg_proc, so that unresolved-collation errors can be thrown at parse time<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-03/msg01520.php <nowiki>Open issues for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Integrate collations with text search configurations<br />
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Integrate collations with to_char() and related functions<br />
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support collation-sensitive equality and hashing functions<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00472.php <nowiki> contrib/citext versus collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a LOCALE option to CREATE DATABASE, as a shorthand<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support multiple simultaneous character sets, per SQL:2008}}<br />
<br />
{{TodoItem<br />
|Improve UTF8 combined character handling?}}<br />
<br />
{{TodoItem<br />
|Add octet_length_server() and octet_length_client()}}<br />
<br />
{{TodoItem<br />
|Make octet_length_client() the same as octet_length()?}}<br />
<br />
{{TodoItem<br />
|Fix problems with wrong runtime encoding conversion for NLS message files}}<br />
<br />
{{TodoItem<br />
|Add URL to more complete multi-byte regression tests<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-07/msg00272.php <nowiki>Multi-byte and client side character encoding tests for copy command..</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix contrib/fuzzystrmatch to work with multibyte encodings<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00138.php <nowiki> dmetaphone woes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions<br />
|Currently we preallocate memory based on worst-case usage.}}<br />
<br />
{{TodoItem<br />
|Add ability to use case-insensitive regular expressions on multi-byte characters<br />
|Currently it works for UTF-8, but not other multi-byte encodings<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php <nowiki>Regexps vs. locale</nowiki>]<br />
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}<br />
}}<br />
<br />
{{TodoItem<br />
|Improve encoding of connection startup messages sent to the client<br />
|Currently some authentication error messages are sent in the server encoding<br />
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php <nowiki>encoding of PostgreSQL messages</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php <nowiki>Re: encoding of PostgreSQL messages</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|More sensible support for Unicode combining characters, normal forms<br />
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net<br />
}}<br />
<br />
== Views and Rules ==<br />
{{TodoItemDone<br />
|Automatically create rules on views so they are updateable, per SQL:2008<br />
|We can only auto-create rules for simple views. For more complex cases users will still have to write rules manually.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php <nowiki>Proposal for updatable views</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2006-08/msg00255.php <nowiki>Updatable views</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php <nowiki>Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle</nowiki>]<br />
* http://wiki.postgresql.org/wiki/Updatable_views<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00035.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00303.php<br />
}}<br />
{{TodoItem<br />
|Add the functionality of the WITH CHECK OPTION clause to CREATE VIEW<br />
}}<br />
{{TodoItem<br />
|Allow VIEW/RULE recompilation when the underlying tables change<br />
|This is both difficult and controversial.<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change2"]<br />
* [http://archives.postgresql.org/message-id/CACk%3DU9NFSzWrEba8G5dZ%3DTZLy3_hx3QXGyCcKVWT%3D4iA1FjMuA@mail.gmail.com VIEW still referring to old name of field]<br />
}}<br />
{{TodoItem<br />
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]<br />
}}<br />
<br />
{{TodoItemDone<br />
|Add materialized views<br />
}}<br />
<br />
{{TodoItem<br />
|Improve ability to modify views via ALTER TABLE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]<br />
}}<br />
<br />
== SQL Commands ==<br />
<br />
{{TodoItem<br />
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT<br />
* [http://dissipatedheat.com/2011/11/10/how-not-to-write-a-patch-for-postgresql/ How not to write this patch.]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve type determination of unknown (NULL or quoted literal) result columns for UNION/INTERSECT/EXCEPT<br />
* [http://archives.postgresql.org/message-id/9799.1302719551@sss.pgh.pa.us <nowiki>UNION construct type cast gives poor error message</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00838.php <nowiki>WIP: grouping sets support</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00466.php <nowiki>Implementation of GROUPING SETS (T431: Extended grouping capabilities)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: &quot;could not open relation 1663/16384/16584: No such file or directory&quot; in a specific combination of transactions with temp tables</nowiki>]<br />
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a GUC variable to warn about non-standard SQL usage in queries}}<br />
<br />
{{TodoItem<br />
|Add SQL-standard MERGE/REPLACE/UPSERT command<br />
|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.<br />
}}<br />
<br />
{{TodoItem<br />
|Add NOVICE output level for helpful messages<br />
|For example, have it warn about unjoined tables. This could also control automatic sequence/index creation messages.<br />
}}<br />
<br />
{{TodoItem<br />
|Allow NOTIFY in rules involving conditionals}}<br />
<br />
{{TodoItem<br />
|Allow EXPLAIN to identify tables that were skipped because of constraint_exclusion<br />
}}<br />
<br />
{{TodoItem<br />
|Simplify dropping roles that have objects in several databases}}<br />
<br />
{{TodoItem<br />
|Allow the count returned by SELECT, etc to be represented as an int64 to allow a higher range of values}}<br />
<br />
{{TodoItem<br />
|Add support for WITH RECURSIVE ... CYCLE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php <nowiki>WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows</nowiki>]}}<br />
<br />
{{TodoItem<br />
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner<br />
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}<br />
<br />
{{TodoItem<br />
|Allow DISTINCT to work in multiple-argument aggregate calls}}<br />
<br />
{{TodoItem<br />
|Add comments on system tables/columns using the information in catalogs.sgml<br />
|Ideally the information would be pulled from the SGML file automatically.}}<br />
<br />
{{TodoItem<br />
|Prevent the specification of conflicting transaction read/write options<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php <nowiki>Re: SET TRANSACTION and SQL Standard</nowiki>]<br />
}}<br />
<br />
{{TodoItemDone<br />
|Support LATERAL subqueries<br />
|Lateral subqueries can reference columns of tables defined outside the subquery at the same level, i.e. ''laterally''.<br />
For example, a LATERAL subquery in a FROM clause could reference tables defined in the same FROM clause.<br />
Currently only the columns of tables defined ''above'' subqueries are recognized.<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php <nowiki>LATERAL</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php <nowiki>Re: LATERAL</nowiki>]<br />
* [http://archives.postgresql.org/message-id/4F5AA202.9020906@gmail.com lateral function as a subquery - WIP patch]<br />
}}<br />
<br />
{{TodoItemDone<br />
|Prevent temporary tables created with ON COMMIT DELETE ROWS from repeatedly truncating the table on every commit if the table is already empty<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00842.php<br />
* http://archives.postgresql.org/pgsql-performance/2010-03/msg00392.php<br />
* http://archives.postgresql.org/pgsql-performance/2010-04/msg00046.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow DELETE and UPDATE to be used with LIMIT and ORDER BY<br />
* http://archives.postgresql.org/pgadmin-hackers/2010-04/msg00078.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01997.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00021.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow PREPARE of cursors}}<br />
<br />
{{TodoItem<br />
|Have DISCARD PLANS discard plans cached by functions<br />
|DISCARD all should do the same.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00431.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid multiple-evaluation of BETWEEN and IN arguments containing volatile expressions<br />
* http://archives.postgresql.org/message-id/4D95B605.2020709@enterprisedb.com<br />
}}<br />
<br />
{{TodoItem<br />
|Fix nested CASE-WHEN constructs<br />
* http://archives.postgresql.org/message-id/4DDCEEB8.50602@enterprisedb.com<br />
}}<br />
<br />
=== CREATE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}<br />
<br />
{{TodoItem<br />
|Have WITH CONSTRAINTS also create constraint indexes<br />
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Move NOT NULL constraint information to pg_constraint<br />
|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?)<br />
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us<br />
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg01223.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00358.php<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add CREATE SCHEMA ... LIKE that copies a schema}}<br />
<br />
{{TodoItem<br />
|Fix CREATE OR REPLACE FUNCTION to not leave objects depending on the function in inconsistent state<br />
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow temporary tables to exist as empty by default in all sessions<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php <nowiki>idea: global temp tables</nowiki>]<br />
* [http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php <nowiki>Re: idea: global temp tables</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg01098.php <nowiki>global temporary tables</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2012-04/msg01148.php Temporary tables under hot standby]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the creation of "distinct" types<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php <nowiki>Distinct types</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider analyzing temporary tables when they are first used in a query<br />
|Autovacuum cannot analyze or vacuum temporary tables.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php <nowiki>autovacuum and temp tables support</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow an unlogged table to be changed to logged<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00437.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00323.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00237.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== UPDATE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|<nowiki>Allow UPDATE tab SET ROW (col, ...) = (SELECT...)</nowiki><br />
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg01308.php <nowiki>Re: [PATCHES] extension for sql update</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00865.php <nowiki>UPDATE using sub selects</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php <nowiki>UPDATE using sub selects</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php <nowiki>Re: UPDATE using sub selects</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00016.php <nowiki>Re: Do we need a TODO? (was Re: Concurrently updating anupdatable view)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows<br />
|This is related to the previous item, which questions whether it even has the right semantics<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ALTER ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Have ALTER TABLE RENAME of a SERIAL column rename the sequence<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CADLWmXUV4LbLhMZL8rYMhCy72aZZLB5BSARPQVgoX0BrxA0FFg@mail.gmail.com renaming implicit sequences]<br />
}}<br />
<br />
{{TodoItem<br />
|Have ALTER SEQUENCE RENAME rename the sequence name stored in the sequence table<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-09/msg00092.php <nowiki>BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00007.php <nowiki>Re: BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add ALTER DOMAIN to modify the underlying data type}}<br />
<br />
{{TodoItem<br />
|Allow ALTER TABLESPACE to move the tablespace to different directories}}<br />
<br />
{{TodoItem<br />
|Allow moving system tables to other tablespaces, where possible<br />
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}<br />
<br />
{{TodoItem<br />
|Have ALTER INDEX update the name of a constraint using that index}}<br />
<br />
{{TodoItem<br />
|Allow column display reordering by recording a display, storage, and permanent id for every column?<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php <nowiki>Column reordering in pg_dump</nowiki>]<br />
* http://archives.postgresql.org/message-id/1324412114-sup-9608@alvh.no-ip.org<br />
}}<br />
<br />
{{TodoItem<br />
|Allow deactivating (and reactivating) indexes via ALTER TABLE<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01191.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add ALTER OPERATOR ... RENAME<br />
|needs to consider effects of changing operator precedence<br />
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]<br />
}}<br />
<br />
{{TodoItemDone<br />
|Add ALTER TABLE ... RENAME RULE<br />
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== CLUSTER ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Automatically maintain clustering on a table<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]<br />
* http://community.enterprisedb.com/git/<br />
* [http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php <nowiki>Re: maintain_cluster_order_v5.patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Allow CLUSTER to be used on a partial index<br />
* http://www.postgresql.org/message-id/CAMkU%3D1zYwoHHsqJ8wfK3GdG_t_a6t4RK-GFDSKymQ0EGP%3DtypA@mail.gmail.com<br />
}} <br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== COPY ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow COPY to report error lines and continue<br />
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure. <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY FROM to create index entries in bulk<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY in CSV mode to control whether a quoted zero-length string is treated as NULL<br />
|Currently this is always treated as a zero-length string, which generates an error when loading into an integer column <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php <nowiki>Re: [PATCHES] allow CSV quote in NULL</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve COPY performance<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01882.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY to report errors sooner<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY to handle other number formats<br />
|E.g. the German notation. Best would be something like WITH DECIMAL ','.<br />
}}<br />
<br />
{{TodoItem<br />
|Allow a stalled COPY to exit if the backend is terminated<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00067.php <nowiki>Re: possible bug not in open items</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== GRANT/REVOKE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow SERIAL sequences to inherit permissions from the base table?}}<br />
<br />
{{TodoItem<br />
|Allow dropping of a role that has connection rights<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php <nowiki>DROP ROLE dependency tracking ...</nowiki>]<br />
}}<br />
{{TodoEndSubsection}}<br />
<br />
=== DECLARE CURSOR ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}<br />
<br />
{{TodoItem<br />
|Provide some guarantees about the behavior of cursors that invoke volatile functions<br />
* [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]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== INSERT ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow INSERT/UPDATE of the system-generated oid value for a row}}<br />
<br />
{{TodoItemDone<br />
|In rules, allow VALUES() to contain a mixture of 'old' and 'new' references}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== SHOW/SET ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}<br />
<br />
{{TodoItem<br />
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count<br />
* [http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php <nowiki>Re: [ADMIN] shared_buffers and shmmax</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ANALYZE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}<br />
<br />
{{TodoItem<br />
|Have EXPLAIN ANALYZE report rows as floating-point numbers<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg01363.php <nowiki>explain analyze rows=%.0f</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00108.php <nowiki>Re: explain analyze rows=%.0f</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve how ANALYZE computes in-doubt tuples<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Window Functions ===<br />
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.<br />
{{TodoSubsection}}<br />
{{TodoItem<br />
|Support creation of user-defined window functions<br />
|We have the ability to create new window functions written in C. Is it<br />
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}<br />
<br />
{{TodoItem<br />
|Implement full support for window framing clauses<br />
|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.<br />
* RANGE BETWEEN ... PRECEDING/FOLLOWING<br />
* EXCLUDE<br />
}}<br />
<br />
{{TodoItem<br />
|Investigate tuplestore performance issues<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php <nowiki>tuplestore potential performance problem</nowiki>]<br />
}}<br />
<br />
{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}<br />
<br />
{{TodoItem<br />
|Teach planner to evaluate multiple windows in the optimal order<br />
|Currently windows are always evaluated in the query-specified order.<br />
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64<br />
}}<br />
<br />
{{TodoItem<br />
|Implement DISTINCT clause in window aggregates<br />
|Some proprietary RDBMSs have implemented it already, so it helps with porting from those.}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Integrity Constraints ==<br />
=== Keys ===<br />
<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve deferrable unique constraints for cases with many conflicts<br />
|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.<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Referential Integrity ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add MATCH PARTIAL referential integrity}}<br />
<br />
{{TodoItem<br />
|Change foreign key constraint for array -&gt; element to mean element in array?<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-10/msg01814.php <nowiki>foreign keys for array/period contains relationships</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Are ri_KeysEqual checks in the RI enforcement triggers still necessary?<br />
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]<br />
}}<br />
<br />
{{TodoItemDone<br />
|Optimize referential integrity checks involving null values<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php <nowiki>Can't ri_KeysEqual() consider two nulls as equal?</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Check Constraints ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Run check constraints only when affected columns are changed<br />
* http://archives.postgresql.org/message-id/1326055327.15293.13.camel@vanquo.pezone.net<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Server-Side Languages ==<br />
<br />
{{TodoItem<br />
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}<br />
<br />
{{TodoItem<br />
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}<br />
<br />
{{TodoItem<br />
|Add more fine-grained specification of functions taking arbitrary data types<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php <nowiki>RfD: more powerful &quot;any&quot; types</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement stored procedures<br />
|This might involve the control of transaction state and the return of multiple result sets<br />
* [http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php <nowiki>PL/pgSQL stored procedure returning multiple result sets (SELECTs)?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php <nowiki>Gathering specs and discussion on feature (post 9.1)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow holdable cursors in SPI}}<br />
<br />
{{TodoItemEasy<br />
|Add SPI_gettypmod() to return a field's typemod from a TupleDesc<br />
* http://archives.postgresql.org/pgsql-hackers/2005-11/msg00250.php<br />
}}<br />
<br />
=== SQL-Language Functions ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Rethink query plan caching and timing of parse analysis within SQL-language functions<br />
|They should work more like plpgsql functions do ...<br />
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00078.php <nowiki>Re: BUG #6019: invalid cached plan on inherited table</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/pgSQL ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}<br />
<br />
{{TodoItem<br />
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki><br />
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow row and record variables to be set to NULL constants, and allow NULL tests on such variables<br />
|Because a row is not scalar, do not allow assignment from NULL-valued scalars.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider keeping separate cached copies when search_path changes<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of NULL row values vs. NULL rows<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php <nowiki>Null row vs. row of nulls in plpgsql</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01973.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve PERFORM handling of WITH queries or document limitation<br />
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00309.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/Perl ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow regex operations in plperl using UTF8 characters in non-UTF8 encoded databases}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/Python ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Develop a trusted variant of PL/Python.}}<br />
<br />
{{TodoItem<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-02/msg01468.php <nowiki>Re: pl/python do not delete function arguments</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a DB-API compliant interface on top of the SPI interface<br />
* http://petereisentraut.blogspot.com/2011/11/plpydbapi-db-api-for-plpython.html<br />
}}<br />
<br />
{{TodoItem<br />
|For functions returning a setof record with a composite type, cache the I/O functions for the composite type<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02007.php<br />
}}<br />
<br />
{{TodoItem<br />
|Fix loss of information during conversion of numeric type to Python float}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/Tcl ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add table function support}}<br />
<br />
{{TodoItem<br />
|Check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, and SPI calls.}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Clients ==<br />
<br />
{{TodoItem<br />
|Add a function like pg_get_indexdef() that report more detailed index information<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Split out pg_resetxlog output into pre- and post-sections<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php<br />
}}<br />
<br />
=== pg_ctl ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve pg_ctl's detection of running postmasters<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00000.php<br />
* http://archives.postgresql.org/pgsql-committers/2011-06/msg00001.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add additional shutdown modes, and change the default?<br />
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg01283.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== psql ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Have psql \ds show all sequences and their settings<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00916.php <nowiki>Re: TODO item: Have psql show current values for a sequence</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00401.php <nowiki>Quick patch: Display sequence owner</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Move psql backslash database information into the backend, use mnemonic commands?<br />
|This would allow non-psql clients to pull the same information out of the database as psql. <br />
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Make psql's \d commands more consistent in their handling of schemas<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php <nowiki>Re: psql and schemas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Make psql's \d commands distinguish default privileges from no privileges<br />
|ACL displays were visibly different for the two cases before we "improved" them by using array_to_string.<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consistently display privilege information for all objects in psql}}<br />
<br />
{{TodoItemEasy<br />
|\s without arguments (display history) fails with libedit, doesn't use pager either<br />
* [http://archives.postgresql.org/pgsql-bugs/2011-06/msg00114.php <nowiki> psql \s not working - OS X</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a \set variable to control whether \s displays line numbers<br />
|Another option is to add \# which lists line numbers, and allows command execution.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Include the symbolic SQLSTATE name in verbose error reports<br />
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add prompt escape to display the client and server versions<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.<br />
|Currently, &quot;wrapped&quot; format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]<br />
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}<br />
<br />
{{TodoItem<br />
|Support the ReST table output format<br />
|Details about the ReST format: http://docutils.sourceforge.net/rst.html#reference-documentation<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg01007.php <nowiki>Proposal: new border setting in psql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00518.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00609.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add option to print advice for people familiar with other databases<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php <nowiki>MySQL-ism help patch for psql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add ability to edit views with \ev<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00023.php <nowiki>Adding \ev view editor?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php<br />
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent psql from sending remaining single-line multi-statement queries after reconnecting<br />
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php<br />
}}<br />
<br />
{{TodoItemEasy<br />
|Add \i option to bring in the specified file as a quoted literal<br />
|This would be useful for creating functions and other areas. Details still need to be worked out.<br />
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00016.php<br />
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00020.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having psql -c read .psqlrc, for consistency<br />
|psql -f already reads .psqlrc<br />
}}<br />
<br />
{{TodoItem<br />
|Allow processing of multiple -f (file) options<br />
}}<br />
<br />
{{TodoItem<br />
|Improve line drawing characters<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00386.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider improving the continuation prompt<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01772.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve speed of tab completion by using LIKE<br />
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== pg_dump / pg_restore ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItemEasy<br />
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}<br />
<br />
{{TodoItemEasy<br />
|Modify pg_dump to create skeleton views for reload (which are then updated via CREATE OR REPLACE VIEW) when views have circular dependencies. This should eliminate the need for the CREATE RULE "_RETURN" hack currently used to address this issue. Thread and additional information here:<br />
* [http://www.postgresql.org/message-id/25554.1360895028@sss.pgh.pa.us Description of change]<br />
|}}<br />
<br />
{{TodoItem<br />
|Add pg_dumpall custom format dumps?<br />
* [http://archives.postgresql.org/pgsql-general/2010-05/msg00509.php pg_dumpall custom format]<br />
|}}<br />
<br />
{{TodoItem<br />
|Avoid using platform-dependent locale names in pg_dumpall output<br />
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get<br />
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.<br />
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Allow selection of individual object(s) of all types, not just tables}}<br />
<br />
{{TodoItem<br />
|In a selective dump, allow dumping of an object and all its dependencies}}<br />
<br />
{{TodoItem<br />
|Add options like pg_restore -l and -L to pg_dump}}<br />
<br />
{{TodoItemDone<br />
|Add support for multiple pg_restore -t options, like pg_dump}}<br />
<br />
{{TodoItem<br />
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}<br />
<br />
{{TodoItem<br />
|Allow pg_dump --clean to drop roles that own objects or have privileges<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}<br />
<br />
{{TodoItem<br />
|Remove support for dumping from pre-7.3 servers<br />
|In 7.3 and later, we can get accurate dependency information from the server. pg_dump still contains a lot of crufty code<br />
to try to deal with the lack of dependency info in older servers, but the usefulness of maintaining that code grows small.}}<br />
<br />
{{TodoItem<br />
|Refactor handling of database attributes between pg_dump and pg_dumpall<br />
|Currently only pg_dumpall emits database attributes, such as ALTER DATABASE SET commands and database-level GRANTs.<br />
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,<br />
but it's unclear whether that will satisfy the demand.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2010-05/msg00010.php summary of the issues]<br />
}}<br />
<br />
{{TodoItem<br />
|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.<br />
|This will require new backend syntax, perhaps COMMENT ON CURRENT DATABASE. This is related to the previous item.}}<br />
<br />
{{TodoItem<br />
|Allow parallel restore of tar dumps<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-02/msg01154.php <nowiki>Re: parallel restore</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Preserve sparse storage of large objects over dump/restore<br />
* [http://archives.postgresql.org/message-id/18789.1349750451@sss.pgh.pa.us <nowiki>TODO item: teach pg_dump about sparsely-stored large objects</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ecpg ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Docs<br />
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}<br />
<br />
{{TodoItem<br />
|Solve cardinality &gt; 1 for input descriptors / variables?}}<br />
<br />
{{TodoItem<br />
|Add a semantic check level, e.g. check if a table really exists}}<br />
<br />
{{TodoItem<br />
|fix handling of DB attributes that are arrays}}<br />
<br />
{{TodoItem<br />
|Fix nested C comments}}<br />
<br />
{{TodoItemEasy<br />
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}<br />
<br />
{{TodoItem<br />
|Make SET CONNECTION thread-aware, non-standard?}}<br />
<br />
{{TodoItem<br />
|Allow multidimensional arrays}}<br />
<br />
{{TodoItem<br />
|Implement COPY FROM STDIN}} <br />
<br />
{{TodoItem<br />
|Provide a way to specify size of a bytea parameter<br />
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]<br />
}}<br />
<br />
{{TodoItemEasy<br />
|Fix small memory leaks in ecpg<br />
|Memory leaks in a short running application like ecpg are not really a problem, but make debugging more complicated}} <br />
<br />
{{TodoItem<br />
|Allow reuse of cursor name variables<br />
* [http://archives.postgresql.org/message-id/20100329113435.GA3430@feivel.credativ.lan <nowiki>Problems with variable cursorname in ecpg</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== libpq ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Prevent PQfnumber() from lowercasing unquoted column names<br />
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}<br />
<br />
{{TodoItem<br />
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add PQexecf() that allows complex parameter substitution<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add SQLSTATE and severity to errors generated within libpq itself<br />
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01425.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for interface/ipaddress binding to libpq<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php <nowiki>SR/libpq - outbound interface/ipaddress binding</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== HTTP===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow access to the database via HTTP<br />
|See [[HTTP_API]]}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Triggers ==<br />
<br />
{{TodoItem<br />
|Improve storage of deferred trigger queue<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php <nowiki>Scaling up deferred unique checks and the after trigger queue</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00023.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow triggers to be disabled in only the current session.<br />
|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.}}<br />
<br />
{{TodoItem<br />
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY<br />
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}<br />
<br />
{{TodoItem<br />
|Allow statement-level triggers to access modified rows}}<br />
<br />
{{TodoItem<br />
|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<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php <nowiki>Statement-level triggers and inheritance</nowiki>]<br />
}}<br />
<br />
{{TodoItemDone<br />
|Add event triggers<br />
}}<br />
<br />
{{TodoItem<br />
|Tighten trigger permission checks<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow BEFORE INSERT triggers on views<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add database and transaction-level triggers<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce locking requirements for creating a trigger<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php <nowiki>Re: Change lock requirements for adding a trigger</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid requirement for "AFTER" trigger functions to return a value<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02384.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow creation of inline triggers<br />
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00708.php<br />
}}<br />
<br />
== Inheritance ==<br />
<br />
{{TodoItem<br />
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-05/msg00285.php <nowiki>Partitioning/inherited tables vs FKs</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00039.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00305.php<br />
}}<br />
<br />
{{TodoItem<br />
|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<br />
|The main difficulty with this item is the problem of creating an index that can span multiple tables.}}<br />
<br />
{{TodoItem<br />
|Determine whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY). If yes, implement it.}}<br />
<br />
{{TodoItem<br />
|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.}}<br />
<br />
== Indexes ==<br />
<br />
{{TodoItem<br />
|Prevent index uniqueness checks when UPDATE does not modify the column<br />
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.<br />
However, HOT already short-circuits this in common cases, so more work might not be helpful.<br />
* http://www.postgresql.org/message-id/CA+TgmoZOyaTanfEvNUdiHBCuu9Zh0JVP1e_UTVbx6Rvj9vFC9Q@mail.gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php <nowiki>Bitmap Indexes: request for feedback</nowiki>]<br />
* http://archives.postgresql.org/message-id/800923.27831.qm@web29010.mail.ird.yahoo.com <br />
}}<br />
<br />
{{TodoItem<br />
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics<br />
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02179.php <br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00459.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02054.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01731.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00894.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00679.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having a larger statistics target for indexed columns and expression indexes. <br />
}}<br />
<br />
{{TodoItem<br />
|Consider smaller indexes that record a range of values per heap page, rather than having one index entry for every heap row<br />
|This is useful if the heap is clustered by the indexed values. <br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00341.php <nowiki>Grouped Index Tuples</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01264.php <nowiki>Grouped Index Tuples</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00465.php <nowiki>Grouped Index Tuples / Clustered Indexes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php <nowiki>Bitmapscan changes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php <nowiki>Re: GIT patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php <nowiki>Re: Index Tuple Compression Approach?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php <nowiki>Re: Index AM change proposals, redux</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00911.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg00128.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multiple indexes to be created concurrently, ideally via a single heap scan<br />
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.<br />
Cluster could definitely benefit from this.<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00093.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider sorting entries before inserting into btree index<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow creation of an index that can do comparisons to test if a value is between two column values<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00757.php <nowiki>Proposal: temporal extension &quot;period&quot; data type</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider using "effective_io_concurrency" for index scans<br />
|Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.<br />
* [http://www.postgresql.org/message-id/CAGTBQpZzf70n0PYJ%3DVQLd+jb3wJGo%3D2TXmY+SkJD6G_vjC5QNg@mail.gmail.com Prefetch index pages for B-Tree index scans]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix problem with btree page splits during checkpoints<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00052.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00184.php<br />
}}<br />
<br />
{{TodoItem<br />
|[http://archives.postgresql.org/pgsql-hackers/2012-05/msg00669.php Support amgettuple() in GIN (useful for exclusion constraints)]<br />
}}<br />
<br />
{{TodoItem<br />
| Allow "loose" or "skip" scans on btree indexes in which the first column has low cardinality<br />
* http://archives.postgresql.org/pgsql-performance/2012-08/msg00159.php<br />
}}<br />
<br />
<br />
=== GIST ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add more GIST index support for geometric data types}}<br />
<br />
{{TodoItem<br />
|Allow GIST indexes to create certain complex index types, like digital trees (see Aoki)}}<br />
<br />
{{TodoItem<br />
|Fix performance issues in contrib/seg and contrib/cube GiST support<br />
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]<br />
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]<br />
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00069.php <nowiki>Re: GiST index performance</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-performance/2009-06/msg00068.php <nowiki>GiST index performance</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|[http://archives.postgresql.org/message-id/4DC8D284-05CF-4E3D-9670-AC9A32C37A36@justatheory.com GiST index support for arrays]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Hash ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add UNIQUE capability to hash indexes}}<br />
<br />
{{TodoItem<br />
|Add hash WAL logging for crash recovery<br />
* http://archives.postgresql.org/pgsql-performance/2011-09/msg00196.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multi-column hash indexes}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Sorting ==<br />
<br />
{{TodoItem<br />
|Consider whether duplicate keys should be sorted by block/offset<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider being smarter about memory and external files used during sorts<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php <nowiki>Re: Sorting Improvements for 8.4</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider detoasting keys before sorting}}<br />
<br />
{{TodoItem<br />
|Allow sorts to use more available memory<br />
* http://archives.postgresql.org/pgsql-hackers/2007-11/msg01026.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01123.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg01957.php<br />
}}<br />
<br />
== Fsync ==<br />
<br />
{{TodoItem<br />
|Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether fsync does anything<br />
|Ideally this requires a separate test program like /contrib/pg_test_fsync that can be run at initdb time or optionally later.<br />
}}<br />
<br />
{{TodoItem<br />
|Consider sorting writes during checkpoint<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php <nowiki>Re: Sorting writes during checkpoint</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg02012.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00278.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00493.php<br />
}}<br />
<br />
== Cache Usage ==<br />
<br />
{{TodoItem<br />
|Provide a way to calculate an &quot;estimated COUNT(*)&quot;<br />
|Perhaps by using the optimizer's cardinality estimates or random sampling.<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php <nowiki>Re: Improving count(*)</nowiki>]<br />
* http://wiki.postgresql.org/wiki/Slow_Counting<br />
}}<br />
<br />
{{TodoItem<br />
|Consider automatic caching of statements at various levels:<br />
* Parsed query tree<br />
* Query execute plan<br />
* Query results <br />
<br />
:<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider increasing internal areas (NUM_CLOG_BUFFERS) when shared buffers is increased<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php <nowiki>Re: slru.c race condition (was Re: TRAP: FailedAssertion(&quot;!((itemid)-&gt;lp_flags &amp; 0x01)&quot;,)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php <nowiki>clog_buffers to 64 in 8.3?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php <nowiki>CLOG Patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider decreasing the amount of memory used by PrivateRefCount<br />
|<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php <nowiki>PrivateRefCount (for 8.3)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php <nowiki>Re: PrivateRefCount (for 8.3)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider allowing higher priority queries to have referenced buffer cache pages stay in memory longer<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve cache lookup speed for sessions accessing many relations<br />
* http://archives.postgresql.org/pgsql-hackers/2012-11/msg00356.php<br />
}}<br />
<br />
== Vacuum ==<br />
<br />
{{TodoItem<br />
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow concurrent inserts to use recently created pages rather than creating new ones<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having single-page pruning update the visibility map<br />
* <nowiki>https://commitfest.postgresql.org/action/patch_view?id=75</nowiki><br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php <nowiki>Re: visibility maps and heap_prune</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]<br />
}}<br />
<br />
{{TodoItem<br />
|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<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php <nowiki>FSM search modes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a more compact data representation for dead tuple locations within VACUUM<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide more information in order to improve user-side estimates of dead space bloat in relations<br />
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve locking behaviour of vacuum during trailing page truncation<br />
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00319.php<br />
* http://archives.postgresql.org/message-id/4D8DF88E.7080205@Yahoo.com<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce the number of table scans performed by vacuum<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00605.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php<br />
}}<br />
<br />
{{TodoItem<br />
|Vacuum Gin indexes in physically order rather than logical order<br />
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg00443.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid creation of the free space map for small tables<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg01751.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00552.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00615.php<br />
}}<br />
<br />
=== Auto-vacuum ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItemEasy<br />
|Issue log message to suggest VACUUM FULL if a table is nearly empty?}}<br />
<br />
{{TodoItem<br />
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation<br />
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can do that. <br />
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent autovacuum from running if an old transaction is still running from the last vacuum<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have autoanalyze of parent tables occur when child tables are modified<br />
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php<br />
* http://archives.postgresql.org/pgsql-performance/2010-10/msg00271.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow visibility map all-visible bits to be set even when an auto-ANALYZE is running<br />
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00356.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow parallel cores to be used by vacuumdb<br />
* [http://archives.postgresql.org/message-id/4F10A728.7090403@agliodbs.com vacuumdb -j]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve autovacuum tuning<br />
* http://www.postgresql.org/message-id/5078AD6B.8060802@agliodbs.com<br />
* http://www.postgresql.org/message-id/20130124215715.GE4528@alvh.no-ip.org<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Locking ==<br />
<br />
{{TodoItem<br />
|Fix priority ordering of read and write light-weight locks<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php <nowiki>lwlocks and starvation</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php <nowiki>Re: lwlocks and starvation</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow UPDATEs on only non-referential integrity columns not to conflict with referential integrity locks<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php <nowiki>Referential Integrity and SHARE locks</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add idle_in_transaction_timeout GUC so locks are not held for long periods of time}}<br />
<br />
{{TodoItem<br />
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Detect deadlocks involving LockBufferForCleanup()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow finer control over who is cancelled in a deadlock<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01727.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a lock timeout parameter<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00485.php <nowiki>SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5</nowiki>]<br />
}}<br />
<br />
== Startup Time Improvements ==<br />
<br />
{{TodoItem<br />
|Experiment with multi-threaded backend for backend creation<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Allow backends to change their database without restart<br />
|This allows for faster server startup.<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00843.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00336.php<br />
}}<br />
<br />
== Write-Ahead Log ==<br />
<br />
{{TodoItem<br />
|Eliminate need to write full pages to WAL before page modification<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01191.php<br />
* [http://archives.postgresql.org/message-id/20120105061916.GB21048@fetter.org WIP double writes]<br />
* [http://archives.postgresql.org/message-id/4EFC449F02000025000441CD@gw.wicourts.gov double writes]<br />
* [http://archives.postgresql.org/message-id/20120110214344.GB21106@fetter.org Double-write with Fast Checksums]<br />
* [http://archives.postgresql.org/message-id/1962493974.656458.1327703514780.JavaMail.root@zimbra-prod-mbox-4.vmware.com double writes using "double-write buffer" approach]<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01463.php<br />
}}<br />
<br />
{{TodoItem<br />
|When full page writes are off, write CRC to WAL and check file system blocks on recovery<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Write full pages during file system write and not when the page is modified in the buffer cache<br />
|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.<br />
* [http://archives.postgresql.org/message-id/CAGvK12UST-tPhyLrSLuSpwFxZbAO79yYrhV2xaLmS2MkUxNUVQ@mail.gmail.com Page Checksums + Double Writes]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce WAL traffic so only modified values are written rather than entire rows<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php <nowiki>Reduction in WAL for UPDATEs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow WAL information to recover corrupted pg_controldata<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Find a way to reduce rotational delay when repeatedly writing last WAL page<br />
|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. <br />
* [http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php <nowiki>500 tpsQL + WAL log implementation</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Speed WAL recovery by allowing more than one page to be prefetched<br />
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay. <br />
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve WAL concurrency by increasing lock granularity<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Be more aggressive about creating WAL files<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php <nowiki>Re: PANIC caused by open_sync on Linux</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-07/msg01075.php <nowiki>PreallocXlogFiles</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-04/msg00556.php <nowiki>WAL/PITR additional items</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have resource managers report the duration of their status changes<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]<br />
}}<br />
<br />
{{TodoItemDone<br />
|Move pgfoundry's xlogdump to /contrib and have it rely more closely on the WAL backend code<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php <nowiki>xlogdump</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Close deleted WAL files held open in *nix by long-lived read-only backends<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]<br />
}}<br />
<br />
== Optimizer / Executor ==<br />
<br />
{{TodoItem<br />
|Improve selectivity functions for geometric operators}}<br />
<br />
{{TodoItem<br />
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold<br />
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00597.php<br />
}}<br />
<br />
{{TodoItem<br />
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}<br />
<br />
{{TodoItem<br />
|Consider compressed annealing to search for query plans<br />
|This might replace GEQO.<br />
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Improve use of expression indexes for ORDER BY <br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php <nowiki>Resjunk sort columns, Heikki's index-only quals patch, and bug #5000</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Modify the planner to better estimate caching effects<br />
* http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow shared buffer cache contents to affect index cost computations<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the CTE (Common Table Expression) optimization fence to be optionally disabled<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00700.php<br />
* http://archives.postgresql.org/pgsql-performance/2012-11/msg00161.php<br />
}}<br />
<br />
=== Hashing ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Consider using a hash for joining to a large IN (VALUES ...) list<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow single batch hash joins to preserve outer pathkeys<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|"lazy" hash tables - look up only the tuples that are actually requested<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid building the same hash table more than once during the same query<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid hashing for distinct and then re-hashing for hash join<br />
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Background Writer ==<br />
<br />
{{TodoItem<br />
|Consider having the background writer update the transaction status hint bits before writing out the page<br />
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.}}<br />
<br />
{{TodoItem<br />
|Consider adding buffers the background writer finds reusable to the free list <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]<br />
}}<br />
<br />
{{TodoItem<br />
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency<br />
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]<br />
}}<br />
<br />
== Concurrent Use of Resources ==<br />
<br />
{{TodoItem<br />
|Do async I/O for faster random read-ahead of data<br />
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]<br />
* [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>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]<br />
* [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>]<br />
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.<br />
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]<br />
}}<br />
<br />
{{TodoItem<br />
|Experiment with multi-threaded backend for better I/O utilization<br />
|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.<br />
* http://archives.postgresql.org/pgsql-performance/2011-02/msg00123.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01139.php<br />
}}<br />
<br />
{{TodoItem<br />
|Experiment with multi-threaded backend for better CPU utilization<br />
|This would allow several CPUs to be used for a single query, such as for sorting or query execution.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00945.php <nowiki>Multi CPU Queries - Feedback and/or suggestions wanted!</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|SMP scalability improvements<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]<br />
}}<br />
<br />
== TOAST ==<br />
<br />
{{TodoItem<br />
|Allow user configuration of TOAST thresholds<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce unnecessary cases of deTOASTing<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce costs of repeat de-TOASTing of values<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]<br />
}}<br />
<br />
== Monitoring ==<br />
{{TodoItem<br />
|Expand pg_stat_activity for easier integration with monitoring tools<br />
|* http://archives.postgresql.org/message-id/4DFA13A5.2060200@2ndQuadrant.com<br />
}}<br />
<br />
{{TodoItem<br />
|Add column to pg_stat_activity that shows the progress of long-running commands like CREATE INDEX and VACUUM<br />
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00203.php <nowiki>EXPLAIN progress info</nowiki>]<br />
* The CLUSTER/VACUUM FULL implementation would also be useful to track this way<br />
}}<br />
<br />
{{TodoItem<br />
|Have pg_stat_activity display query strings in the correct client encoding<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php <nowiki>pg_stats queries versus per-database encodings</nowiki>]<br />
}}<br />
<br />
{{TodoItemEasy<br />
|Expose pg_controldata via an SQL interface<br />
|Helpful for monitoring replicated databases<br />
* http://archives.postgresql.org/message-id/4B901D73.8030003@agliodbs.com<br />
* [http://archives.postgresql.org/message-id/4B959D7A.6010907@joeconway.com initial patch]<br />
}}<br />
<br />
{{TodoItem<br />
| Add entry creation timestamp column to pg_stat_replication<br />
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00694.php<br />
}}<br />
<br />
{{TodoItem<br />
| Allow reporting of stalls due to wal_buffer wrap-around<br />
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00826.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure pg_stat_database columns tup_returned and tup_fetched to return meaningful values<br />
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org<br />
}}<br />
<br />
== Miscellaneous Performance ==<br />
<br />
{{TodoItem<br />
|Use mmap() rather than SYSV for shared buffers?<br />
|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.<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00750.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00756.php<br />
}}<br />
<br />
{{TodoItem<br />
|Rather than consider mmap()-ing in 8k pages, consider mmap()'ing entire files into a backend?<br />
|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.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01239.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider ways of storing rows more compactly on disk:<br />
* Reduce the row header size?<br />
* Consider reducing on-disk varlena length from four bytes to two because a heap row cannot be more than 64k in length}}<br />
<br />
{{TodoItem<br />
|Consider transaction start/end performance improvements<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php <nowiki>Reducing Transaction Start/End Contention</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow configuration of backend priorities via the operating system<br />
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.<br />
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider increasing the minimum allowed number of shared buffers<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call<br />
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation<br />
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Sort large UPDATE/DELETEs so it is done in heap order<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider decreasing the I/O caused by updating tuple hint bits<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid the requirement of freezing pages that are infrequently modified <br />
|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<br />
* http://archives.postgresql.org/message-id/4BF701CF.2090205@agliodbs.com<br />
* http://archives.postgresql.org/pgsql-hackers/2010-06/msg00082.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode<br />
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Restructure truncation logic to be more resistant to failure<br />
|This also involves not writing dirty buffers for a truncated or dropped relation<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider adding logic to increase large tables by more than 8k<br />
|This would reduce file system fragmentation<br />
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00337.php<br />
}}<br />
<br />
== Miscellaneous Other ==<br />
<br />
{{TodoItem<br />
|Deal with encoding issues for filenames in the server filesystem<br />
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}<br />
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}<br />
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}<br />
}}<br />
<br />
{{TodoItem<br />
|Deal with encoding issues in the output of localeconv()<br />
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]<br />
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]<br />
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports<br />
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]<br />
* [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>]<br />
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]<br />
}}<br />
<br />
{{TodoItemDone<br />
| Provide [http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html#LIBPQ-CONNECT-FALLBACK-APPLICATION-NAME fallback_application_name] in contrib/pgbench, oid2name, and dblink.<br />
* {{MessageLink|w2g9837222c1004070216u3bc46b3ahbddfdffdbfb46212@mail.gmail.com|fallback_application_name and pgbench}}<br />
}}<br />
<br />
{{TodoItem<br />
|Add 64-bit support to /contrib/pgbench<br />
* http://archives.postgresql.org/pgsql-hackers/2010-07/msg00153.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00705.php<br />
}}<br />
<br />
== Source Code ==<br />
<br />
{{TodoItemEasy<br />
|Remove warnings created by -Wcast-align}}<br />
<br />
{{TodoItem<br />
|Move platform-specific ps status display info from ps_status.c to ports}}<br />
<br />
{{TodoItem<br />
|Add optional CRC checksum to heap and index pages<br />
|One difficulty is how to prevent hint bit changes from affecting the computed CRC checksum.<br />
* http://archives.postgresql.org/message-id/19934.1226601952%40sss.pgh.pa.us<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00002.php <nowiki>Re: Block-level CRC checks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01028.php <nowiki>double-buffering page writes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00524.php <nowiki>Re: Block-level CRC checks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01101.php <nowiki>Re: Block-level CRC checks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00011.php <nowiki>Re: Block-level CRC checks</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00249.php<br />
* http://archives.postgresql.org/message-id/20111221215913.GA4536@fetter.org<br />
* http://archives.postgresql.org/message-id/CA+U5nMJzQyxcObkpNAf1SYTX-gO_Mom3O9JXHnGpxRo1kXJ7ww@mail.gmail.com<br />
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00128.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00113.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00172.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-03/msg00001.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-03/msg00188.php<br />
* http://www.postgresql.org/message-id/1352422901.31259.28.camel@sussancws0025<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a faster CRC32 algorithm<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow cross-compiling by generating the zic database on the target system}}<br />
<br />
{{TodoItem<br />
|Improve NLS maintenance of libpgport messages linked onto applications}}<br />
<br />
{{TodoItem<br />
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}<br />
<br />
{{TodoItem<br />
|Allow creation of universal binaries for Darwin<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider GnuTLS if OpenSSL license becomes a problem<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php<br />
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider making NAMEDATALEN more configurable in future releases}}<br />
<br />
{{TodoItem<br />
|Research use of signals and sleep wake ups<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow C++ code to more easily access backend code<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider simplifying how memory context resets handle child contexts<br />
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Create three versions of libpgport to simplify client code<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement the non-threaded Avahi service discovery protocol<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce data row alignment requirements on some 64-bit systems<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Restructure TOAST internal storage format for greater flexibility<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Add regression tests for pg_dump/restore<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01967.php <nowiki>"make install-check-pg_dump" target in src/regress]</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Research different memory allocation methods for lists<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php <br />
}}<br />
<br />
{{TodoItem<br />
| Consider removing the attribute options cache<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00039.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure /contrib section<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00705.php<br />
}}<br />
<br />
{{TodoItem<br />
| Consider adding explicit huge page support<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00123.php<br />
}}<br />
<br />
=== /contrib/pg_upgrade ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Handle large object comments<br />
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.<br />
}}<br />
<br />
{{TodoItem<br />
|Consider using pg_depend for checking object usage in version.c<br />
}}<br />
<br />
{{TodoItem<br />
|If reindex is necessary, allow it to be done in parallel with pg_dump custom format<br />
}}<br />
<br />
{{TodoItem<br />
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary<br />
|pg_class.oid is not preserved so schema.tablename must be used.<br />
* [http://archives.postgresql.org/message-id/CAAZKuFaWdLkK8eozSAooZBets9y_mfo2HS6urPAKXEPbd-JLCA@mail.gmail.com pg_upgrade and statistics]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve testing, perhaps using the buildfarm<br />
|The buildfarm has access to multiple versions of PostgreSQL.<br />
}}<br />
<br />
{{TodoItem<br />
|Create machine-readable output of pg_controldata<br />
|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.<br />
}}<br />
<br />
{{TodoItem<br />
|Find cleaner way to start/stop dedicated servers for upgrades<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00275.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a way to run pg_upgrade on standby servers<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00453.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00056.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Windows ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Remove configure.in check for link failure when cause is found}}<br />
<br />
{{TodoItem<br />
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}<br />
<br />
{{TodoItem<br />
|Allow psql to use readline once non-US code pages work with backslashes}}<br />
<br />
{{TodoItem<br />
|Fix problem with shared memory on the Win32 Terminal Server}}<br />
<br />
{{TodoItem<br />
|Improve signal handling<br />
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Convert MSVC build system to remove most batch files<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support pgxs when using MSVC}}<br />
<br />
{{TodoItem<br />
|Fix MSVC NLS support, like for to_char()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Find a correct rint() substitute on Windows<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix global namespace issues when using multiple terminal server sessions<br />
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}<br />
<br />
{{TodoItem<br />
|Change from the current autoconf/gmake build system to cmake<br />
* [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>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve consistency of path separator usage<br />
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net<br />
}}<br />
<br />
{{TodoItem<br />
|Fix cross-compiling on Windows<br />
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce file statistics overhead on directory reads<br />
* http://www.postgresql.org/message-id/1338325561.82125.YahooMailNeo@web39304.mail.mud.yahoo.com<br />
}}<br />
<br />
<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Wire Protocol Changes ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow dynamic character set handling}}<br />
<br />
{{TodoItem<br />
|Let the client indicate character encoding of database names, user names, and passwords<br />
* http://www.postgresql.org/message-id/16160.1360540050@sss.pgh.pa.us}}<br />
<br />
{{TodoItem<br />
|Add decoded type, length, precision}}<br />
<br />
{{TodoItem<br />
|Mark result columns as known-not-null when possible<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide more control over planner treatment of statements being prepared}}<br />
<br />
{{TodoItem<br />
|Use compression<br />
|If SSL is used, hopefully avoid the overhead of key negotiation and encryption<br />
* http://archives.postgresql.org/pgsql-hackers/2012-06/msg00793.php<br />
}}<br />
<br />
{{TodoItem<br />
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}<br />
<br />
{{TodoItem<br />
|Set protocol for wire format negotiation<br />
* [http://archives.postgresql.org/message-id/CACMqXCKkGrGXxQhjHCKCe0B8hn6sTt-1sdgHZOSGQMxrusOsQA@mail.gmail.com GUC_REPORT for protocol tunables]<br />
}}<br />
<br />
{{TodoItem<br />
|Make sure upgrading to a 4.1 protocol version will actually work smoothly<br />
* [http://archives.postgresql.org/message-id/28307.1318255008@sss.pgh.pa.us Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Documentation ==<br />
<br />
{{TodoItemEasy <br />
| Add contrib functions to the index<br />
* Add the functions and GUCs in the contrib modules to [http://www.postgresql.org/docs/current/static/sql-createindex.html the documentation index]: [http://archives.postgresql.org/message-id/50A2E173.6030404@2ndQuadrant.com per list discussion]<br />
}}<br />
<br />
{{TodoItem<br />
|Convert single quotes to apostrophes in the PDF documentation<br />
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide a manpage for postgresql.conf<br />
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}<br />
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}<br />
}}<br />
<br />
{{TodoItem<br />
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools<br />
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}<br />
}}<br />
<br />
{{TodoItem<br />
|Consider changing documentation format from SGML to XML<br />
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]<br />
* http://archives.postgresql.org/pgsql-docs/2011-04/msg00020.php<br />
* http://wiki.postgresql.org/wiki/Switching_PostgreSQL_documentation_from_SGML_to_XML<br />
}}<br />
<br />
{{TodoItem<br />
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard<br />
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com<br />
}}<br />
<br />
{{TodoItem<br />
|Add diagrams to the documentation<br />
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php<br />
}}<br />
<br />
== Exotic Features ==<br />
<br />
{{TodoItem<br />
|Add pre-parsing phase that converts non-ISO syntax to supported syntax<br />
|This could allow SQL written for other databases to run without modification.}}<br />
<br />
{{TodoItem<br />
|Allow plug-in modules to emulate features from other databases}}<br />
<br />
{{TodoItem<br />
|Add features of Oracle-style packages<br />
|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 &quot;packages&quot; syntax at all.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider allowing control of upper/lower case folding of unquoted identifiers<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]<br />
* [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>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add autonomous transactions<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Give query progress indication<br />
* [[Query progress indication]]<br />
}}<br />
<br />
{{TodoItem<br />
|Rethink our type system<br />
* [[Rethinking datatypes]]<br />
}}<br />
<br />
== Features We Do ''Not'' Want ==<br />
<br />
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.<br />
<br />
{{TodoItem<br />
|All backends running as threads in a single process (not wanted)<br />
|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.}}<br />
<br />
{{TodoItem<br />
|"Oracle-style" optimizer hints (not wanted)<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Embedded server (not wanted)<br />
|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.}}<br />
<br />
{{TodoItem<br />
|Obfuscated function source code (not wanted)<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Indeterminate behavior for the GROUP BY clause (not wanted)<br />
|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.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]<br />
}}<br />
<br />
</div><br />
<br />
[[Category:Todo]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=GSoC_2012&diff=16442GSoC 20122012-03-26T16:58:34Z<p>Theory: Fix typo.</p>
<hr />
<div>== Projects ==<br />
<br />
The GSoC projects will be listed here when chosen.<br />
<br />
<br />
== What is GSoC? ==<br />
<br />
Google Summer of Code (GSoC) is a global program that offers student developers stipends to write code for various open source software projects. We have worked with several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Since its inception in 2005, the program has brought together over 4,500 students and more than more than 4,000 mentors & co-mentors from over 85 countries worldwide, all for the love of code. Through Google Summer of Code, accepted student applicants are paired with a mentor or mentors from the participating projects, thus gaining exposure to real-world software development scenarios and the opportunity for employment in areas related to their academic pursuits. In turn, the participating projects are able to more easily identify and bring in new developers. Best of all, more source code is created and released for the use and benefit of all.<br />
<br />
PostgreSQL has an official summer of code page: http://www.postgresql.org/developer/summerofcode.html<br />
<br />
== Advice for Students ==<br />
<br />
We have developed the following [http://www.postgresql.org/developer/summerofcodeadvice Advice for Students] page to get you started.<br />
<br />
Also, students who discuss their proposals with Postgres project members *before* the application deadline are much more likely to be successful.<br />
<br />
== Mailing list for student questions ==<br />
<br />
For GSoC program questions and discussion, please subscribe to:<br />
<br />
http://archives.postgresql.org/pgsql-students/<br />
<br />
We can have non-code related discussions on this list, and help answer questions about proposal writing. <br />
<br />
Discussion of code should be done on the list for the specific project a student is working on. <br />
<br />
== IRC ==<br />
<br />
We have an IRC channel at #postgresql and you are welcome to answer questions. Our GSoC Admins are: selenamarie, agliodbs and xzilla. Do not DM them without asking first! <br />
<br />
You are welcome to ping any of us in the channel, or ask the channel general questions about a proposal. If you do not find help in the channel, feel free to send an email to pgsql-students@postgresql.org for help.<br />
<br />
== Proposal Format ==<br />
<br />
Students are responsible for writing a proposal and submitting it to Google before the application deadline. The following outline was adapted from the [http://www.perlfoundation.org/how_to_write_a_proposal Perl Foundation open source proposal HOWTO]. A strong proposal will include:<br />
<br />
* Project Title<br />
* Name of proposer and email<br />
* Synopsis<br />
* Benefits to the PostgreSQL Community<br />
* Quantifiable results <br />
* Project Details<br />
* Inch-stones (project broken into small, distinct chunks)<br />
* Project Schedule<br />
* Completeness Criteria<br />
* Bio<br />
**Blog<br />
**Github<br />
**@Twitter<br />
<br />
<br />
== Project Ideas ==<br />
<br />
=== Tool improvments ===<br />
<br />
* pg_dump/pg_restore libraries as shared objects (better error-handling, process-monitoring, objects selection and creating in-memory dumps)<br />
<br />
* Develop an iOS-native interface for PostgreSQL for Apple devices. This might be a fork of pgAdmin, or a brand-new interface.<br />
<br />
* phpPgAdmin improvements: Make sure to check our TODO and feature request pages:<br />
** https://github.com/phppgadmin/phppgadmin/raw/master/TODO<br />
** https://sourceforge.net/tracker/?group_id=37132&atid=418983<br />
<br />
* PGXN: Improve the PGXN command-line client for installation and upgrade of extensions. http://www.pgxn.org<br />
<br />
=== Driver Improvements ===<br />
<br />
Any of the following PostgreSQL drivers could use work on feature support and performance:<br />
<br />
* JDBC<br />
* Erlang<br />
* Node.js (integrate with 9.2's JSON and PL/v8)<br />
* Ruby<br />
<br />
===Pgadmin improvements===<br />
<br />
Rewrite the object browser and connection management code to:<br />
* Ensure nodes are always up to date when clicked, and do not display out of date cached data<br />
* Properly [attempt to] reconnect to the database when connections are lost, without losing application state.<br />
* Pool database connections, and close/reopen them when needed rather than leave them idle for long periods of time.<br />
<br />
Query tool enhancements:<br />
* Allow queries to be executed on multiple databases simultaneously, displaying results from all databases.<br />
* Support psql \ commands, including \copy and \connect<br />
* Support execution of multiple data returning statements in a single query, displaying the results from each.<br />
<br />
Others:<br />
* Redesign the Table properties dialogue to incorporate all sub-dialogues in one easy-to-use dialogue (existing sub-dialogues will remain for direct inspection of sub-objects).<br />
* Data import/export tool, designed to be easy to extend for new import/export formats. Should include a data transformation and mapping layer (using Python?) to allow data to be manipulated during import/export.<br />
<br />
===Foreign Data Wrappers===<br />
<br />
[http://www.postgresql.org/docs/current/static/fdwhandler.html Write a foreign data wrapper] for [http://www.ibm.com/software/data/db2/ DB2], [http://firebirdsql.org/ Firebird], or anything else that seems interesting or fun.<br />
<br />
===Advanced Features===<br />
<br />
'''JSON Indexing/Extraction''': Add indexable element extraction to PostgeSQL's JSON type which does not depend on PL/v8.<br />
<br />
'''Materialized Views''': add support for one type of automated updating of materialized views: sychronous, asyncronous-queued, or scheduled.<br />
<br />
===PGXN Improvements===<br />
<br />
* Improve the [http://pgxn.org PGXN search] such that all document types are searched in a single query. This would require re-organizing how documents are indexed and improving on the [http://incubator.apache.org/lucy/ Lucy] search engine implementation.<br />
* Add interactive features to the [https://github.com/pgxn/pgxn-api/wiki/ PGXN API] and thus the [http://pgxn.org/ main site]. Features might include:<br />
** Download counts<br />
** An Atom feed<br />
** Authentication/identification<br />
** Ratings/Likes<br />
** Diffs between releases of distributions<br />
* Add features to [http://manager.pgxn.org/ PGXN Manager]:<br />
** Improve localization support<br />
** Add an email gateway so that PGXN users can be emailed via @pgxn.org addresses<br />
** Add ability to delete or archive releases or distributions<br />
** [https://github.com/pgxn/pgxn-manager/issues/11 Add a UI for maintenance tasks]<br />
** [https://github.com/pgxn/pgxn-manager/issues/10 Add support for instant mirror propagation]<br />
** [https://github.com/pgxn/pgxn-manager/issues/9 Add a release callback interface]<br />
** Implement an [https://github.com/pgxn/pgxn-manager/issues/8 ownership admin interface] and [https://github.com/pgxn/pgxn-manager/issues/6 owner UI], so that users can add co-owners or reassign ownsership of their distributions to other users, and admins can do so for other users<br />
** [https://github.com/pgxn/pgxn-manager/issues/7 Add a user admin interface]<br />
<br />
== Key Info ==<br />
* March 9th, Mentoring Application Due<br />
* April 6th, Student Applications Deadline<br />
<br />
* [http://google-opensource.blogspot.com/2012/02/mentoring-organization-applications-now.html Announcement for GSoC 2012]<br />
* [http://www.google-melange.com/ GSOC 2012 Home page ]<br />
* [https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs GSOC 2012 FAQ]<br />
* [http://www.postgresql.org/developer/summerofcode Postgres GSOC Page, Needs Updating!]<br />
<br />
== Project Admins ==<br />
<br />
Coming soon<br />
<br />
== 2012 Mentors ==<br />
<br />
* Pavel Golub - Postgres external tools developer<br />
* Heikki Linnakangas - Postgres Committer<br />
* Dave Page - Former mentor - pgAdmin, Windows, Packaging, Infrastructure<br />
* Jehan-Guillaume de Rorthais - phpPgAdmin<br />
* Dave Cramer - JDBC<br />
* Kevin Grittner - SSI, transaction engine<br />
* Magnus Hagander - Windows support, SSL, www.postgresql.org<br />
* David Wheeler - Perl, PGXN.org<br />
* Stephen Frost - Patch reviewer, developer<br />
<br />
== Past Success ==<br />
<br />
Need to add<br />
<br />
== GOALS: ==<br />
* usable code<br />
** useful/novel ideas<br />
** research projects<br />
* longer term contributors<br />
<br />
== TODOs: ==<br />
<br />
* Kick-off Meeting for Community Members<br />
* Update GSOC page<br />
* Advertising?<br />
* Blog that we're participating and seeking students<br />
* Round of private emails to people who have participated in the past: Heikki, Simon, Mark<br />
** request interest, and then follow up in asking about possible topics for students<br />
* Mentor recruitment and then email to -hackers<br />
** do this much later when we have some proposals in?<br />
<br />
* Recruitment -- no organized group effort?<br />
** -announce, -general, -hackers<br />
** user group lists<br />
** phppgadmin/pgadmin<br />
** berkeley<br />
** Univ. of Maryland -- contact them?<br />
<br />
* Identify the commitfest that the code will be submitted to<br />
<br />
== Expectations ==<br />
<br />
* Stuff to keep students together:<br />
** Regular blogging from students<br />
** weekly group IRC checkin? -- two checkin times maybe?<br />
<br />
* Have students communicate on -hackers where appropriate (didn't really work?)<br />
** Or other relevant -devel lists<br />
<br />
* Mailing list<br />
** pgsql-students (?) vs. -hackers (?) maybe up to mentor?<br />
** mentors mailing list -admin mailing list, berkus said?<br />
** students mailing list via gsoc<br />
<br />
[[Category:Google Summer of Code]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=GSoC_2012&diff=16441GSoC 20122012-03-26T16:58:06Z<p>Theory: Add PGXN Improvements.</p>
<hr />
<div>== Projects ==<br />
<br />
The GSoC projects will be listed here when chosen.<br />
<br />
<br />
== What is GSoC? ==<br />
<br />
Google Summer of Code (GSoC) is a global program that offers student developers stipends to write code for various open source software projects. We have worked with several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Since its inception in 2005, the program has brought together over 4,500 students and more than more than 4,000 mentors & co-mentors from over 85 countries worldwide, all for the love of code. Through Google Summer of Code, accepted student applicants are paired with a mentor or mentors from the participating projects, thus gaining exposure to real-world software development scenarios and the opportunity for employment in areas related to their academic pursuits. In turn, the participating projects are able to more easily identify and bring in new developers. Best of all, more source code is created and released for the use and benefit of all.<br />
<br />
PostgreSQL has an official summer of code page: http://www.postgresql.org/developer/summerofcode.html<br />
<br />
== Advice for Students ==<br />
<br />
We have developed the following [http://www.postgresql.org/developer/summerofcodeadvice Advice for Students] page to get you started.<br />
<br />
Also, students who discuss their proposals with Postgres project members *before* the application deadline are much more likely to be successful.<br />
<br />
== Mailing list for student questions ==<br />
<br />
For GSoC program questions and discussion, please subscribe to:<br />
<br />
http://archives.postgresql.org/pgsql-students/<br />
<br />
We can have non-code related discussions on this list, and help answer questions about proposal writing. <br />
<br />
Discussion of code should be done on the list for the specific project a student is working on. <br />
<br />
== IRC ==<br />
<br />
We have an IRC channel at #postgresql and you are welcome to answer questions. Our GSoC Admins are: selenamarie, agliodbs and xzilla. Do not DM them without asking first! <br />
<br />
You are welcome to ping any of us in the channel, or ask the channel general questions about a proposal. If you do not find help in the channel, feel free to send an email to pgsql-students@postgresql.org for help.<br />
<br />
== Proposal Format ==<br />
<br />
Students are responsible for writing a proposal and submitting it to Google before the application deadline. The following outline was adapted from the [http://www.perlfoundation.org/how_to_write_a_proposal Perl Foundation open source proposal HOWTO]. A strong proposal will include:<br />
<br />
* Project Title<br />
* Name of proposer and email<br />
* Synopsis<br />
* Benefits to the PostgreSQL Community<br />
* Quantifiable results <br />
* Project Details<br />
* Inch-stones (project broken into small, distinct chunks)<br />
* Project Schedule<br />
* Completeness Criteria<br />
* Bio<br />
**Blog<br />
**Github<br />
**@Twitter<br />
<br />
<br />
== Project Ideas ==<br />
<br />
=== Tool improvments ===<br />
<br />
* pg_dump/pg_restore libraries as shared objects (better error-handling, process-monitoring, objects selection and creating in-memory dumps)<br />
<br />
* Develop an iOS-native interface for PostgreSQL for Apple devices. This might be a fork of pgAdmin, or a brand-new interface.<br />
<br />
* phpPgAdmin improvements: Make sure to check our TODO and feature request pages:<br />
** https://github.com/phppgadmin/phppgadmin/raw/master/TODO<br />
** https://sourceforge.net/tracker/?group_id=37132&atid=418983<br />
<br />
* PGXN: Improve the PGXN command-line client for installation and upgrade of extensions. http://www.pgxn.org<br />
<br />
=== Driver Improvements ===<br />
<br />
Any of the following PostgreSQL drivers could use work on feature support and performance:<br />
<br />
* JDBC<br />
* Erlang<br />
* Node.js (integrate with 9.2's JSON and PL/v8)<br />
* Ruby<br />
<br />
===Pgadmin improvements===<br />
<br />
Rewrite the object browser and connection management code to:<br />
* Ensure nodes are always up to date when clicked, and do not display out of date cached data<br />
* Properly [attempt to] reconnect to the database when connections are lost, without losing application state.<br />
* Pool database connections, and close/reopen them when needed rather than leave them idle for long periods of time.<br />
<br />
Query tool enhancements:<br />
* Allow queries to be executed on multiple databases simultaneously, displaying results from all databases.<br />
* Support psql \ commands, including \copy and \connect<br />
* Support execution of multiple data returning statements in a single query, displaying the results from each.<br />
<br />
Others:<br />
* Redesign the Table properties dialogue to incorporate all sub-dialogues in one easy-to-use dialogue (existing sub-dialogues will remain for direct inspection of sub-objects).<br />
* Data import/export tool, designed to be easy to extend for new import/export formats. Should include a data transformation and mapping layer (using Python?) to allow data to be manipulated during import/export.<br />
<br />
===Foreign Data Wrappers===<br />
<br />
[http://www.postgresql.org/docs/current/static/fdwhandler.html Write a foreign data wrapper] for [http://www.ibm.com/software/data/db2/ DB2], [http://firebirdsql.org/ Firebird], or anything else that seems interesting or fun.<br />
<br />
===Advanced Features===<br />
<br />
'''JSON Indexing/Extraction''': Add indexable element extraction to PostgeSQL's JSON type which does not depend on PL/v8.<br />
<br />
'''Materialized Views''': add support for one type of automated updating of materialized views: sychronous, asyncronous-queued, or scheduled.<br />
<br />
===PGXN Improvements===<br />
<br />
* Improve the [http://pgxn.org PGXN search] such that all document types are searched in a single query. This would require re-organizing how documents are indexed and improving on the [Lucy|http://incubator.apache.org/lucy/] search engine implementation.<br />
* Add interactive features to the [https://github.com/pgxn/pgxn-api/wiki/ PGXN API] and thus the [http://pgxn.org/ main site]. Features might include:<br />
** Download counts<br />
** An Atom feed<br />
** Authentication/identification<br />
** Ratings/Likes<br />
** Diffs between releases of distributions<br />
* Add features to [http://manager.pgxn.org/ PGXN Manager]:<br />
** Improve localization support<br />
** Add an email gateway so that PGXN users can be emailed via @pgxn.org addresses<br />
** Add ability to delete or archive releases or distributions<br />
** [https://github.com/pgxn/pgxn-manager/issues/11 Add a UI for maintenance tasks]<br />
** [https://github.com/pgxn/pgxn-manager/issues/10 Add support for instant mirror propagation]<br />
** [https://github.com/pgxn/pgxn-manager/issues/9 Add a release callback interface]<br />
** Implement an [https://github.com/pgxn/pgxn-manager/issues/8 ownership admin interface] and [https://github.com/pgxn/pgxn-manager/issues/6 owner UI], so that users can add co-owners or reassign ownsership of their distributions to other users, and admins can do so for other users<br />
** [https://github.com/pgxn/pgxn-manager/issues/7 Add a user admin interface]<br />
<br />
== Key Info ==<br />
* March 9th, Mentoring Application Due<br />
* April 6th, Student Applications Deadline<br />
<br />
* [http://google-opensource.blogspot.com/2012/02/mentoring-organization-applications-now.html Announcement for GSoC 2012]<br />
* [http://www.google-melange.com/ GSOC 2012 Home page ]<br />
* [https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs GSOC 2012 FAQ]<br />
* [http://www.postgresql.org/developer/summerofcode Postgres GSOC Page, Needs Updating!]<br />
<br />
== Project Admins ==<br />
<br />
Coming soon<br />
<br />
== 2012 Mentors ==<br />
<br />
* Pavel Golub - Postgres external tools developer<br />
* Heikki Linnakangas - Postgres Committer<br />
* Dave Page - Former mentor - pgAdmin, Windows, Packaging, Infrastructure<br />
* Jehan-Guillaume de Rorthais - phpPgAdmin<br />
* Dave Cramer - JDBC<br />
* Kevin Grittner - SSI, transaction engine<br />
* Magnus Hagander - Windows support, SSL, www.postgresql.org<br />
* David Wheeler - Perl, PGXN.org<br />
* Stephen Frost - Patch reviewer, developer<br />
<br />
== Past Success ==<br />
<br />
Need to add<br />
<br />
== GOALS: ==<br />
* usable code<br />
** useful/novel ideas<br />
** research projects<br />
* longer term contributors<br />
<br />
== TODOs: ==<br />
<br />
* Kick-off Meeting for Community Members<br />
* Update GSOC page<br />
* Advertising?<br />
* Blog that we're participating and seeking students<br />
* Round of private emails to people who have participated in the past: Heikki, Simon, Mark<br />
** request interest, and then follow up in asking about possible topics for students<br />
* Mentor recruitment and then email to -hackers<br />
** do this much later when we have some proposals in?<br />
<br />
* Recruitment -- no organized group effort?<br />
** -announce, -general, -hackers<br />
** user group lists<br />
** phppgadmin/pgadmin<br />
** berkeley<br />
** Univ. of Maryland -- contact them?<br />
<br />
* Identify the commitfest that the code will be submitted to<br />
<br />
== Expectations ==<br />
<br />
* Stuff to keep students together:<br />
** Regular blogging from students<br />
** weekly group IRC checkin? -- two checkin times maybe?<br />
<br />
* Have students communicate on -hackers where appropriate (didn't really work?)<br />
** Or other relevant -devel lists<br />
<br />
* Mailing list<br />
** pgsql-students (?) vs. -hackers (?) maybe up to mentor?<br />
** mentors mailing list -admin mailing list, berkus said?<br />
** students mailing list via gsoc<br />
<br />
[[Category:Google Summer of Code]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=Postgres-XC&diff=16338Postgres-XC2012-02-28T20:25:07Z<p>Theory: Update latest released versions, with links.</p>
<hr />
<div>== Project Overview ==<br />
Postgres-XC (eXtensible Cluster) is a multi-master write-scalable PostgreSQL cluster based on shared-nothing architecture, developed by NTT and EnterpriseDB. Introductory information is found [[media:XC_pgday_eu_20101207a.pdf|here (PDF)]]. Architecture description is found [[media:PG-XC_Architecture.pdf|here (PDF)]].<br />
<br />
Features of PG-XC include:<br />
<br />
# Write‐scalable PostgreSQL cluster<br />
#* More than 3.4× scalability performance speedup with five servers, compared with pure PostgreSQL (DBT‐1)<br />
# Synchronous multi‐master configuration<br />
#* Any update to any master is visible from other masters immediately.<br />
# Table location transparent<br />
#* Can continue to use the same applications.<br />
#* No change in transaction handling.<br />
# Based upon PostgreSQL<br />
# Same API to Apps as PostgreSQL<br />
<br />
Postgres-XC was formerly known as Postgres-2, but the name was changed due to concerns over it not being unique.<br />
<br />
== Project Status ==<br />
Now under development.<br />
<br />
* [https://sourceforge.net/projects/postgres-xc/ Version 0.9.9 is available.<br />
<br />
* License changed from LGPL to BSD.<br />
<br />
* Gave a talk at [http://2010.pgday.eu/start PGDay.eu 2010].<br />
<br />
* Another talk in the JPUG [http://www.postgresql.jp/wg/shikumi/shikumi_19_folder/shikumi_19/ seminar] (in Japanese).<br />
<br />
== Project Property ==<br />
<br />
This is Postgres-XC property according to the guideline as suggested<br />
[[ClusteringProject|here]].<br />
<br />
=== Overview ===<br />
<br />
Please take a look at the top of this page.<br />
<br />
=== Status ===<br />
<br />
[https://sourceforge.net/projects/postgres-xc/files/Version_0.9.7/ Version 0.9.7] released.<br />
<br />
=== Status Detail ===<br />
<br />
Infrastructure for the scalability and transaction management has already been done.<br />
Now the team is working to extend the coverage of statements, as well as HA feature.<br />
Latest version is [https://sourceforge.net/projects/postgres-xc/files/Version_0.9.7/ v0.9.7]. Version 1.0 release is planned at the end of March, 2012.<br />
<br />
Details of the roadmap can be found in the [http://postgres-xc.sourceforge.net/ project home page].<br />
<br />
=== Contacts ===<br />
<br />
Developer: Koichi Suzuki, Mason Sharp, Pavan Deolasee, Andrei Martsinchyk, [http://michael.otacoo.com/ Michael Paquier] and Takayuki Suto.<br />
<br />
Preferred method of contact: write to pgsql-cluster-hackers at postgresql.org, postgres-xc-general at lists.sourceforge.net or postgres-xc-developers at lists.sourceforge.net.<br />
<br />
=== URL ===<br />
<br />
We have [https://sourceforge.net/projects/postgres-xc/ Development Page] and<br />
[https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Main_Page Project Home].<br />
<br />
PGCon2011 Cluster Summit page is [[PgCon2011CanadaClusterSummit|here]]<br />
<br />
PGCon2011 Developer Meeting page is [[PgCon_2011_Developer_Meeting|here]]<br />
<br />
=== General Information ===<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="width: 100%; border-collapse: collapse; border: 1px solid #ccc; font-size: 90%;"<br />
|-<br />
| style="background: #eee" |'''Scalability''' || Evaluated with ten servers. Potentially twenty to thirty servers.<br />
|-<br />
| style="background: #eee" |'''Read scaling''' || Yes<br />
|-<br />
| style="background: #eee" |'''Write scaling''' || Yes<br />
|-<br />
| style="background: #eee" |'''Triggers/procedures''' || Procedure: Yes || Trigger will be supported by the end of September, 2011.<br />
|-<br />
| style="background: #eee" |'''Parallel query''' || Now some of the queries can be executed in parallel in multiple data nodes. || <br />
|-<br />
| style="background: #eee" |'''Failover/High Availability''' || No || Will be available by the end of June, 2011<br />
|-<br />
| style="background: #eee" |'''Online provisioning''' || No || <br />
|-<br />
| style="background: #eee" |'''PostgreSQL upgrades''' || No || All the node should be upgraded at the same time.<br />
|-<br />
| style="background: #eee" |'''Detached node/WAN''' || No || Postgres-XC depends upon high speed communication.<br />
|-<br />
| style="background: #eee" |'''PostgreSQL core modifications required''' || Yes || <br />
|-<br />
| style="background: #eee" |'''Programming languages''' || C, flex, bison, bash and ruby (just for utilities) || <br />
|-<br />
| style="background: #eee" |'''Licensing''' || BSD || <br />
|-<br />
| style="background: #eee" |'''Complete clustering solution''' || Targetted || High-availability feature will be added.<br />
|-<br />
| style="background: #eee" |'''PostgreSQL versions''' || 9.0.3 || Planning to move to 9.1<br />
|}<br />
<br />
=== Model Summary ===<br />
<br />
Synchronous multi-master.<br />
<br />
=== Model description ===<br />
<br />
Extracting transaction management into single server to provide transaction ID and snapshot, as well as other global values. Thus Postgres-XC provides consistent database view to any transactions running on any master.<br />
<br />
Each table can be partitioned or replicated, as specified in CREATE TABLE statement.<br />
<br />
=== Use-case ===<br />
<br />
Transactional use case.<br />
<br />
* Large scale transactional application,<br />
<br />
* Integration of multiple database applications.<br />
<br />
* Dynamic load balancing in cloud environment, assigning computing resource dynamically depending upon prospect load.<br />
<br />
=== Drawbacks ===<br />
<br />
Although some statement cannot be handled (e.g., WITH clause), the gap to full PostgreSQL statement is becomming narrower as new releases are made available. We need some research work for solutions on following issues.<br />
<br />
* Tuple relocation. When the value of distribution column is updated, we have to relocate the tuple to appropriate one.<br />
* Global Deadlock detection. As discussed in cluster-hackers mailing list, there's no experience how long it will take to detect it and if it is reasonable compared with simple timeout mechanism.<br />
* Global constraint. Can we enforce unique or other constraint exclusion globally in multiple data nodes?<br />
* WITH clause<br />
<br />
=== Support ===<br />
<br />
[https://www.oss.ecl.ntt.co.jp/ossc/ NTT] (page is in Japanese) and [http://www.enterprisedb.com/ EnterpriseDB] are supporting the project.<br />
<br />
=== Other Information ===<br />
<br />
The project is now actively enhancing the feature. Please visit [http://postgres-xc.sourceforge.net/ Project Home Page] for details of our roadmap.<br />
<br />
<br />
[[Category:Replication]]<br />
[[Category:Clustering]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=Project_Hosting&diff=16148Project Hosting2012-01-10T22:00:17Z<p>Theory: Update GitHub info. It does provide a wiki, which is great for docs (e.g., https://github.com/pgxn/pgxn-api/wiki/) and it does provide a place to upload release files.</p>
<hr />
<div>PostgreSQL provides several way to integrate with [http://www.postgresql.org/docs/9.0/interactive/external-projects.html External Projects], both inside and outside of the core database itself. The PostgreSQL Development Group (PGDG) provides some resources toward hosting PostgreSQL projects.<br />
<br />
The current home for many PostgreSQL projects is [http://pgfoundry.org/ PgFoundry], a free resource provided by the PGDG. PgFoundry provides projects with a full set of resources, including version control, mailing lists with archives, and bug tracking. The only source code management (SCM) repository type supported is CVS. Because many projects want more modern SCM options, some existing and new projects have instead hosted their resources at other places. An upgrade to PgFoundry is not expected, and the PGDG is exploring a plan to eventually shut the site down. New projects should consider an alternative hosting site.<br />
<br />
Some add-on projects are considered critical to PostgreSQL adoption. One such category are drivers for popular programming languages that are not shipped with the database itself (JDBC, ODBC, others). Critical projects can request space on [http://git.postgresql.org git.postgresql.org] along with a [http://www.postgresql.org/community/lists/ mailing list].<br />
<br />
[https://github.com/ github] is a popular site for hosting projects using the git SCM. It provides some basic project tools such as an issue tracker, wiki, and releases. There is a [https://github.com/postgres-mirror PostgreSQL mirror at github] you can fork to easily create patches against the database source code. github doesn't provide a good way to provide any sort of mailing list for the project. Some projects have combined github for the main project hosting with [http://groups.google.com Google groups] to provide an archived mailing list.<br />
<br />
Other sites that are possible places to host a PostgreSQL related project at include:<br />
* [http://sourceforge.net/ sourceforge]<br />
* [http://code.google.com/ Google code]<br />
* [https://launchpad.net/ Launchpad]<br />
* [https://bitbucket.org/ bitbucket]<br />
* [http://tuxfamily.org/en/about TuxFamily]<br />
<br />
Each of these sites has a different mix of features it supports. Support for the preferred SCM of the developer is often the first thing considered, since some of these sites only support one of them. For example, github only handles git, and Launchpad only supports Bazaar.</div>Theoryhttps://wiki.postgresql.org/index.php?title=Postgres_Open_Talks_2011&diff=15444Postgres Open Talks 20112011-09-20T16:56:25Z<p>Theory: /* Michigan Room */</p>
<hr />
<div>= Postgres Open Talks 2011 =<br />
<br />
Here will be the Postgres Open talks. <br />
<br />
== Tutorials: Wednesday September 14, 2011 ==<br />
<br />
=== Mayfair Room ===<br />
* [http://bunsen.credativ.com/~jco/2011/migrating.pdf Migration to PostgreSQL - preparation and methodology]<br />
* [http://www.scribd.com/doc/65304692/Scaling-With-SkyTools Scaling With Skytools]<br />
<br />
=== Governor's Suite ===<br />
* [http://momjian.us/main/writings/pgsql/administration.pdf Mastering PostgreSQL Administration]<br />
<br />
== Sessions: Thursday September 15, 2011 ==<br />
<br />
=== Cotillion Room ===<br />
* [http://www.pgexperts.com/document.html?id=53 Keynote: The next 25 years]<br />
* [http://bonesmoses.org/presentations/nvram_fun_profit.pdf NVRAM for Fun and Profit]<br />
* [http://wiki.postgresql.org/wiki/File:Pg_query_analysis_20110914.odp Identifying Slow Queries and Fixing Them Slides]<br />
<br />
=== Mayfair Room ===<br />
* [http://joshwilliams.name/talks/monitoring/ Monitoring the Heck out of Your Database]<br />
* [http://www.slideshare.net/DBNess/honey-i-shrunk-the-database-9273383 Honey, I Shrunk the Database]<br />
* [http://wiki.postgresql.org/images/0/0b/Postgresql_django_extensions.pdf Writing Django Extensions for PostgreSQL]<br />
* [http://wiki.postgresql.org/images/8/8e/Logging.odp Logging - Not Just for Lumberjacks] (speaker notes included)<br />
<br />
=== Governors' Suite ===<br />
<br />
* [http://heroku-postgres-talk.heroku.com/ Heroku Postgres]<br />
* [http://wiki.postgresql.org/images/5/58/Why_you_should_not_move_away_from_Oracle.pdf Why you should NOT move away from Oracle]<br />
* [http://bunsen.credativ.com/~mme/2011/MissionImpossible.pdf Mission impossible? Can I replace my most important databases with PostgreSQL?]<br />
* [http://wiki.postgresql.org/images/0/0c/BillingSystemForTELCO_technical.pdf Billing System for a TELCO based on PostgreSQL - technical description]<br />
* [[media:HP_Postgres_Insight_RS.pdf|HP Performs Large-scale Deployment of Postgres with its Remote Support Software]]<br />
<br />
=== Michigan Demos ===<br />
<br />
* [http://www.enterprisedb.com/resources-community/webcasts-podcasts-videos/webcasts/postgres-cloud-introduction-postgres-plus-clou Postgres In the Cloud: an Introduction to Postgres Plus Cloud Server]<br />
<br />
== Sessions: Friday September 16, 2011 == <br />
<br />
<br />
=== Cotillion Room ===<br />
<br />
* [http://michael.otacoo.com/wp-content/uploads/2011/09/20110916_pgopen_xc.pdf Postgres-XC]<br />
* [http://momjian.us/main/writings/pgsql/locking.pdf Unlocking the Postgres Lock Manager]<br />
<br />
=== Mayfair Room ===<br />
* [http://wiki.postgresql.org/images/7/79/Accelerating_Local_Search_PostgreSQL_91.pdf Accelerating Local Search With PostgreSQL 9.1]<br />
* [http://bunsen.credativ.com/~jco/2011/plr-PostgresOpen-2011.pdf PL/R -- The Fast Path to Advanced Analytics]<br />
<br />
=== Michigan Room ===<br />
<br />
* [http://wiki.postgresql.org/images/7/7c/Development_Funding.pdf Get Your Preferred Feature Developed!]<br />
* [http://wiki.postgresql.org/images/0/0e/Center_of_your_dataverse.pdf PostgreSQL at the centre of your dataverse]<br />
* [http://wiki.postgresql.org/images/5/56/Database_sing.pdf We write the code that makes the database sing]<br />
* [http://wiki.postgresql.org/images/f/fa/Slony_Versus_Developers.pdf Slony Versus Developers]<br />
* [http://wiki.postgresql.org/images/7/7f/Adam-lowry-postgresopen2011.pdf Postgres at Urban Airship]<br />
<br />
[[Category:PostgreSQL Events]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=File:Development_Funding.pdf&diff=15443File:Development Funding.pdf2011-09-20T16:54:45Z<p>Theory: Presented at Postgres Open 2011.
So you've got PostgreSQL integrated deep into the core of your business, and developed enough expertise that you're pushing the boundaries of what it can do. Now what? This brief outlines simple steps to take to find the personnel, financial, and temporal resources necessary to get your favorite features developed and committed to the core product.</p>
<hr />
<div>Presented at Postgres Open 2011.<br />
<br />
So you've got PostgreSQL integrated deep into the core of your business, and developed enough expertise that you're pushing the boundaries of what it can do. Now what? This brief outlines simple steps to take to find the personnel, financial, and temporal resources necessary to get your favorite features developed and committed to the core product.</div>Theoryhttps://wiki.postgresql.org/index.php?title=GSoC_2011&diff=13242GSoC 20112011-03-08T17:08:41Z<p>Theory: /* 2011 Mentors */</p>
<hr />
<div>== Project Ideas ==<br />
<br />
* Implement a new Foreign Data Wrapper. For ODBC, for example.<br />
* Please add ideas here!<br />
<br />
== Projects ==<br />
<br />
The GSoC projects for 2011 are:<br />
<br />
* TBD :)<br />
<br />
We are also working on a [http://twitter.com/selenamarie/gsoc2011 twitter list] for those involved this year. If you are missing, please send us your info:<br />
<br />
== Key Info ==<br />
* March 7th - 11th, Mentoring Application Due<br />
* March 29th - April 9th, Student Applications Due<br />
<br />
* [http://google-opensource.blogspot.com/2011/02/mentoring-organization-applications-now.html Announcement for GSoC 2011]<br />
* [http://http://www.google-melange.com// GSOC 2011 Home page ]<br />
* [http://http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs GSOC 2011 FAQ]<br />
* [http://www.postgresql.org/developer/summerofcode Postgres GSOC Page, Needs Updating!]<br />
* [https://twitter.com/selenamarie/gsoc2011 Twitter stream of mentors and students]<br />
<br />
== Project Admins ==<br />
* Selena Deckelmann - Co-admin, Mentor Summit attendee.<br />
* Josh Berkus - Co-admin, Mentor Summit attendee.<br />
* Robert Treat - Past mentor 2x, co-admin, Mentor Summit attendee. <br />
<br />
== 2011 Mentors ==<br />
* Dave Page - Former mentor - pgAdmin, Windows, Packaging, Infrastructure <br />
* Heikki Linnakangas - Postgres Committer<br />
* Magnus Hagander - Postgres Committer, Windows, pgAdmin<br />
* Guillaume Lelarge - pgAdmin<br />
* Jehan-Guillaume de Rorthais - phpPgAdmin<br />
* Joe Abbate - Python-related, infrastructure<br />
* David E. Wheeler - Perl-related, extensions, PGXN<br />
<br />
=== additional reviewers === <br />
* Josh Berkus - auto-configuration, performance testing<br />
* Selena Deckelmann - configuration, testing<br />
<br />
== 2010 Mentors ==<br />
* Dave Page - Former mentor - pgAdmin, Windows, Packaging, Infrastructure <br />
* Robert Haas - CommitFest Manager<br />
* Heikki Linnakangas - Postgres Committer<br />
* Magnus Hagander - Postgres Committer, Windows, pgAdmin<br />
* Guillaume Lelarge - pgAdmin<br />
* Jehan-Guillaume de Rorthais - phpPgAdmin<br />
=== additional reviewers === <br />
* Josh Berkus - auto-configuration, performance testing<br />
* Andreas Scherbaum - performance, ddl, configuration<br />
<br />
== Past Success ==<br />
* Florian - read-only on snapshots, no advancement of xid on select statements<br />
* Ivan - Full-Text Support in phpPgAdmin<br />
* Mickael Deloison - pgScript engine for pgAdmin<br />
* Luis Alberto Ochoa Paz - Graphical query builder for pgAdmin<br />
* Leonardo Sapiras - browsing data through FK in phpPgAdmin + some additionnal stuffs<br />
<br />
== GOALS: ==<br />
* usable code<br />
** useful/novel ideas<br />
** research projects<br />
* longer term contributors<br />
<br />
== TODOs: ==<br />
<br />
* Kick-off Meeting for Community Members<br />
* Update GSOC page<br />
* Advertising?<br />
* Blog that we're participating and seeking students<br />
* Round of private emails to people who have participated in the past: Heikki, Simon, Mark<br />
** request interest, and then follow up in asking about possible topics for students<br />
* Mentor recruitment and then email to -hackers<br />
** do this much later when we have some proposals in?<br />
<br />
* Recruitment -- no organized group effort?<br />
** -announce, -general, -hackers<br />
** user group lists<br />
** phppgadmin/pgadmin<br />
** berkeley<br />
** Univ. of Maryland -- contact them?<br />
<br />
* Identify the commitfest that the code will be submitted to<br />
<br />
== Expectations ==<br />
<br />
* Stuff to keep students together:<br />
** Regular blogging from students<br />
** weekly group IRC checkin? -- two checkin times maybe?<br />
<br />
* Have students communicate on -hackers where appropriate (didn't really work?)<br />
** Or other relevant -devel lists<br />
<br />
* Mailing list<br />
** pgsql-students (?) vs. -hackers (?) maybe up to mentor?<br />
** mentors mailing list -admin mailing list, berkus said?<br />
** students mailing list via gsoc<br />
<br />
[[Category:Google Summer of Code]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PgCon_2011_Developer_Meeting&diff=13206PgCon 2011 Developer Meeting2011-03-03T20:04:23Z<p>Theory: Added my name; re-ordered alphabetically by last name.</p>
<hr />
<div>A meeting of the most active PostgreSQL developers and senior figures from PostgreSQL-developer-sponsoring companies is being planned for Wednesday 18th May, 2010 near the University of Ottawa, prior to pgCon 2011. 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).<br />
<br />
This is a PostgreSQL Community event. Room and refreshments/food sponsored by EnterpriseDB. Other companies sponsored attendance for their developers.<br />
<br />
== Time & Location ==<br />
<br />
The meeting will be from 9AM to 5PM, and will be in the "Albion B" room at:<br />
<br />
Novotel Ottawa<br />
33 Nicholas Street<br />
Ottawa<br />
Ontario<br />
K1N 9M7<br />
<br />
Food and drink will be provided throughout the day, including breakfast from 8AM.<br />
<br />
== Attendees ==<br />
<br />
The following people have RSVPed to the meeting:<br />
<br />
* Josh Berkus<br />
* Selena Deckelmann<br />
* Stephen Frost<br />
* Magnus Hagander<br />
* Dave Page<br />
* David Wheeler<br />
<br />
== Proposed Agenda Items ==<br />
<br />
Please list proposed agenda items here:<br />
<br />
* Review of the move from CVS to GIT (Dave)<br />
<br />
== Agenda ==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|08:00<br />
|Breakfast<br />
|<br />
|-<br />
|08:45 - 09:00<br />
|Welcome and introductions<br />
|Dave Page<br />
|-<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 10:45<br />
|Coffee break<br />
|<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:30 - 13:30<br />
|Lunch <br />
|<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|15:00 - 15:15<br />
|Tea break<br />
|<br />
|-<br />
|16:45 - 17:00<br />
|Any other business<br />
|Dave Page<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|17:00<br />
|Finish<br />
| <br />
|}</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=11770PGXN2010-08-14T05:46:24Z<p>Theory: Update CPAN::Meta::Spec link.</p>
<hr />
<div>This document outlines the specification for the creation of PGXN, the PostgreSQL Extension Network (formerly known as "PGAN"). The purpose of PGXN is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PGXN.<br />
<br />
=Upload Server=<br />
<br />
The models for the upload server include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (upload.pgxn.org), if possible use existing postgresql.org logins. From there, users can upload release packages to the site and add or delete release managers.<br />
<br />
Once a package is uploaded, it is considered released and its name registered to the uploading user. The upload server will add its metadata to its database and add the package and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PGXN. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via the upload server.<br />
<br />
The upload server will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to the upload server as Gzip-, Bzip2-, or Zip-compressed packages. The upload server will unpack it, validate its contents, and repack it with Zip compression into a file ending with <code>.pgz</code>. A distribution package is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PGXN Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://search.cpan.org/perldoc?CPAN::Meta::Spec CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PGXN. The names "PostgreSQL", "Postgres", "pgsql", and "psql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed, defined one of a set of predefined strings, a URL, or a structure identifying the license name and URL.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>: This is the standard [http://www.postgresql.org/docs/current/static/xfunc-c.html#XFUNC-C-PGXS PGXS] build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>: The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>: May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>: Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>: Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>: Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PGXN Directory=<br />
<br />
The entire directory of PGXN will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PGXN for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PGXN database and listed on the PGXN Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PGXN will contain information about all the distributions on PGXN, including relevant metadata. It will also include information about registered PGXN users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow visitors to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from the upload server hourly, and will include a feed of recent releases uploaded to PGXN. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PGXN to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PGXN Client=<br />
<br />
The PGXN client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN] and [http://search.cpan.org/perldoc?cpanminus cpanminus] clients. Essentially, it will provide an interface to easily download, build, test, and install PGXN distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN clients.<br />
<br />
For the initial implementation, the PGXN client will assume that extensions can be built using [http://www.postgresql.org/docs/current/static/xfunc-c.html#XFUNC-C-PGXS PGXS] with:<br />
<br />
<pre>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</pre><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PGXN client will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PGXN client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. To the extent that PGXS-powered <code>make</code> works on a given platform, the client will support it.<br />
<br />
The PGXN client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PGXN index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PGXN is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PGXN infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PGXN=<br />
<br />
Once the initial implementation of PGXN is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution package ready for release on PGXN.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the package, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PGXN RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PGXN extensions.<br />
* PGXN Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PGXN?''' Open-source PostgreSQL extension release packages. The current contrib extensions serve as the model for the contents of such packages. Following the [http://www.cpan.org/misc/ZCAN.html CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PGXN?''' Non-package files (that is, files that are not tarballs, bzip-balls, or zip archives), closed-source distributions, and distributions with no license.<br />
* '''Who can release on PGXN?''' Any registered user.<br />
* '''Who can register for PGXN?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PGXN needs to [http://en.wikipedia.org/wiki/KISS_principle KISS]. Longer answer: No. Again following the [http://www.cpan.org/misc/ZCAN.html CPAN example], PGXN "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of PGXN is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL. PGXN will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting. The only thing in common with pgFoundry is uploading release packages. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PGXN client will be updated to take advantage of new features. Such improvements are expected to make PGXN more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PGXN.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PGXN will take advantage of them, but none are required in order to bootstrap PGXN.<br />
* '''How will PGXN make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PGXN with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PGXN client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves such that a compiler is no longer required, the PGXN client will be modified as appropriate to take advantage of it. This applies not specifically to Windows, but to the ability of the core installer (or any future community-supported installer) to work on ''any'' platform.<br />
* '''What kind of security will it have?''' Each release package will have an accompanying SHA1 hash that the PGXN client will verify before installing an extension.<br />
<br />
=References=<br />
* [http://www.cpan.org/misc/ZCAN.html The Zen of Comprehensive Archive Networks]<br />
* [http://use.perl.org/comments.pl?sid=9630&cid=14713 Easier than you think] (comment on ZCAN)<br />
* [http://search.cpan.org/perldoc?CPAN::Meta::Spec The CPAN Meta spec]<br />
* [http://wiki.postgresql.org/wiki/ExtensionPackaging PostgreSQL Extensions Proposal]<br />
* [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]<br />
* [http://trac.parrot.org/parrot/wiki/ModuleEcosystem The Parrot Module Ecosystem]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PgCon_2010_Developer_Meeting&diff=11760PgCon 2010 Developer Meeting2010-08-13T22:22:54Z<p>Theory: Update name of PGXN.</p>
<hr />
<div>A meeting of the most active PostgreSQL developers and senior figures from PostgreSQL-developer-sponsoring companies is being planned for Wednesday 19th May, 2010 near the University of Ottawa, prior to pgCon 2010. 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).<br />
<br />
This is a PostgreSQL Community event. Room and lunch sponsored by EnterpriseDB. Other companies sponsored attendance for their developers.<br />
<br />
== Actions ==<br />
<br />
* Josh & Selena will '''[[PostgreSQL_9.0_Open_Items|track open items]]''' and make sure they get listed or tracked and resolved.<br />
* Selena to '''get reviewers start on commitfest early - around June 15'''<br />
* '''Branch''' on July 1, CF July 15.<br />
* '''Announce a plan''' for next development schedule.<br />
* '''No more branching''' for alphas.<br />
* Stephen's '''intern to develop PerformanceFarm application'''. Will need help from Dunstan/Drake etc.<br />
* Kaigai, Stephen, Smith, etc. to get together at pgCon and hash out some more security provider issues.<br />
* Magnus to set up git environment emulator.<br />
* Andrew to publish checklist of how to set up your Git<br />
* '''Move to Git August 17-20''': Magnus, Haas, Dunstan. Frost will be out.<br />
* Koichi to '''extract patch from PostgresXC for snapshot cloning''' and submit.<br />
* Koichi to '''come up with proposed patch design for XID feed'''<br />
* Develop '''specification for commit sequence / LSN data'''<br />
* '''[[DDL Triggers]] Wiki page to be updated''' with spec by Jan, Greg M, et al<br />
* Dimitri to do '''patch (regarding extensions..)''' More detail?<br />
* EDB '''to decide on opening code''' or not for SQL/MED<br />
* '''Review Itagaki's git repo code''': Heikki, Peter SQL/MED<br />
* '''Itagaki to keep working on API''' -- what about Peter? SQL/MED<br />
* '''Document what the plan is to do a conversion upgrade''' (Greg Smith) -- pg_update<br />
* '''Copy Zdenek's code''' (Greg Smith) related to pg_update<br />
<br />
== Time & Location ==<br />
<br />
The meeting will be from 9AM to 5PM, and will be in the O'Connor room at:<br />
<br />
Arc The Hotel<br />
140 Slater Street<br />
Ottawa<br />
Ontario<br />
K1P 5H6<br />
<br />
[http://maps.google.ca/maps?f=q&source=s_q&hl=en&geocode=&q=ARC+THE.HOTEL+|+140++Slater+Street,+Ottawa,+Ontario,+K1P+5H6&sll=49.891235,-97.15369&sspn=45.043582,78.486328&ie=UTF8&hq=ARC+THE.HOTEL+|&hnear=140+Slater+St,+Ottawa,+ON&z=16&iwloc=A Google Maps]<br />
<br />
Food and drink will be provided throughout the day.<br />
<br />
== Invitees ==<br />
<br />
The following people have RSVPed to the meeting:<br />
<br />
* Oleg Bartunov<br />
* Josh Berkus<br />
* Joe Conway<br />
* Jeff Davis<br />
* Selena Deckelmann<br />
* Andrew Dunstan<br />
* David Fetter<br />
* Dimitri Fontaine<br />
* Marc Fournier<br />
* Stephen Frost<br />
* Magnus Hagander<br />
* Robert Haas<br />
* Tatsuo Ishii<br />
* Takahiro Itagaki<br />
* KaiGai Kohei<br />
* Marko Kreen<br />
* Tom Lane<br />
* Heikki Linnakangas<br />
* Michael Meskes<br />
* Bruce Momjian<br />
* Dave Page<br />
* Teodor Sigaev<br />
* Greg Sabino Mullane<br />
* Greg Smith<br />
* Greg Stark<br />
* Koichi Suzuki<br />
* Joshua Tolley<br />
* Robert Treat<br />
* Jan Wieck<br />
<br />
== Agenda ==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|09:00<br />
|Tea, coffee upon arrival <br />
|<br />
|-<br />
|09:15 - 09:25<br />
|Welcome and introductions<br />
|Dave Page<br />
|-<br />
|09:25 - 09:45<br />
|Review of the 9.0 development process <br />
|Dave Page<br />
|-<br />
|09:45 - 10:35<br />
|Development Priorities for 9.1: General discussion <br />
|Josh Berkus<br />
|-<br />
|10:35 - 10:45<br />
|9.1 Development timeline<br />
|Robert Treat<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:45 - 11:00<br />
|Coffee break<br />
|<br />
|-<br />
|11:00 - 11:15<br />
|Performance QA/Performance Farm planning update<br />
|Greg Smith<br />
|-<br />
|11:15 - 11:50<br />
|Advanced access control features [[:Image:Pgcon2010-dev-security.pdf|(Slides)]]<br />
* Steps to support [[ESP|external security providers]]<br />
* [[RLS#Issues|Issues]] of row-level access control<br />
|KaiGai Kohei<br />
|-<br />
|11:50 - 12:30<br />
|CVS to GIT: The finale?<br />
|Dave Page<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:30 - 13:30<br />
|Lunch <br />
|<br />
|-<br />
|13:30 - 13:55<br />
|[[ClusterFeatures#Export_snapshots_to_other_sessions|Snapshot Cloning]]<br />
|Koichi Suzuki<br />
|-<br />
|13:55 - 14:20<br />
|[[ClusterFeatures#XID_feed|XID feed for clones]]<br />
|Koichi Suzuki<br />
|-<br />
|14:20 - 14:45<br />
|[[ClusterFeatures#Modification_trigger_into_core_.2F_Generalized_Data_Queue|General Modification Queue]]<br />
|Itagaki Takahiro, Jan Wieck, Marko Kreen<br />
|-<br />
|14:45 - 15:10<br />
|[[ClusterFeatures#DDL_Triggers|DDL "triggers"]]<br />
|Jan Wieck<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|15:10 - 15:25<br />
|Tea break<br />
|<br />
|-<br />
|15:25 - 15:55<br />
|[[SQL/MED]] [[:Image:Pgcon2010-dev-sqlmed.pdf|(Slides from Heikki)]]<br />
* Including: [[ClusterFeatures#Function_scan_push-down|function scan push-down]]<br />
|Itagaki Takahiro<br />
|-<br />
|15:55 - 16:20<br />
|Status report on Modules [[:Image:Pgcon2010-dev-extensions.pdf|(Slides)]]<br />
|Dimitri Fontaine<br />
|-<br />
|16:20 - 16:45<br />
|In-place upgrade with pg_migrator progress<br />
|Bruce Momjian<br />
|-<br />
|16:45 - 17:00<br />
|Any other business<br />
|Dave Page<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|17:00<br />
|Finish<br />
| <br />
|}<br />
<br />
== Minutes ==<br />
<br />
= 2010 PostgreSQL Developer Meeting =<br />
<br />
Ottawa, Canada<br />
<br />
Present: Tatsuo Ishii, Andrew Dunstan, Bruce Momjian, David Fetter, Jeff Davis, Itagaki Takahiro, Koichi Suzuki, Josh Berkus, Dave Page, Dimitri Fontaine, Marko Kreen, Michael Meskes, Joe Conway, Josh Tolley, Greg Sabino-Mullaine, Selena Deckelman, Stephen Frost, Robert Treat, Robert Haas, Magnus Hagander, Kohei Kaigai, Heikki Linnakangas, Tom Lane, Jam Wieck, Oleg Bartunov, Teodor Sigaev, Marc Fournier, Greg Smith, Greg Stark, Peter Eisentraut (via Skype)<br />
<br />
== Review of The 9.0 Development Process ==<br />
<br />
How did the commitfest work? Do we feel that the process worked in general, do we like Robert's CF application? What other parts of the process should we improve?<br />
<br />
David Fetter commented that the writable CTE patch went through more than one CF without adequate feedback, and the patch got rejected. Should we not allow things to be bumped, or not bumped twice? Still listed as open on November Commitfest. RH thinks feedback was provided but it might not have been very clear. It ''was'' reviewed more than once. RT: maybe we shouldn't be so quick to bump people in the last CF. Writeable CTE wasn't bumped until Feb. 10. Part of the issue is that it's a very complicated patch.<br />
<br />
JB feels that integration/testing needs to be more structured. Still amorphous. If we had more structure, maybe it would go faster. RH we had a lot of open items, we closed them an released Beta1. Agrees that we need more concrete critera. BMomj: we end up with a pile of really hard problems which we don't know how to fix. Even now can't fix max_standby_delay. Needs to be a fire under someone. Open items list is a big win, but doesn't show the scope of the problem. Didn't have anything on open items list until this AM for Beta. Need to reconstitute list.<br />
<br />
If stuff is on the open items list it stops release. DF: maybe we should have ratings of complex/not? Perhaps we need release manager to keep up on open items etc.? Or Beta manager. Not everyone knows what every open item is. Someone should track the list and see status. Need list to know what to work on. JB would like to put stuff on the open items list. If there's a thread on hackers put it on the list.<br />
<br />
How do we get all the big patches in the first commitfest or second instead of last? Assumes people are working while releasing. Why didn't HS get into first commitfest. Post-CF, prerelease is long and delays development, people take a vacation for 6 months. Also the CF reviews were not very good for big patches. CFs worked well for small/medium patches. But for big patches not so great. KNNGiST and WriteableCTE not so great. HS at least didn't get into last commitfest.<br />
<br />
How much of a problem is this issue going to be for 9.1? Do we have anything that large? Synchronous Replication. SQL/MED?<br />
<br />
Josh & Selena will track open items and make sure they get listed or tracked and resolved.<br />
<br />
== Priorities for 9.1 ==<br />
<br />
See [[PgCon_2010_Developer_Meeting#Development_Priorities_for_9.1|priority grid]] below.<br />
<br />
== Timeline for 9.1 ==<br />
<br />
Treat: Release in July, have an immediate commitfest of pending stuff. Will we release in July? If we're late, do we want to drop a commitfest and have shorter cycle? Maybe the development cycle should go, even if the release is delayed? Lane doesn't think we have enough manpower for that.<br />
<br />
Issue is that people are waiting 6 months to resume development. Are there enough reviewers, though? Maybe we could have a reviewfest. Haas thinks that we have manpower. Berkus likes the idea of a reviewfest, new people. Haas says that we could commit stuff or at least put it "pending commit". Smith says that pruning patches would be valuable. What's the main bottleneck of people? Maybe Kevin could run it.<br />
<br />
We would need to branch first. Which would involve backpatching. Branch on July 1, first CF on July 15? Or 15 and August 1? Tom Lane: if we're not close to releaseable by July 1, then it's not feasible. Frost would like to have reviewfest in June. We could ask for reviews right now. RRRs need more direction. Selena will help.<br />
<br />
In the future, do we want to start earlier? We should get more people to help with getting to beta. Get people on open items list. Put it on the commitfest app? Magnus: but that makes it closer to a bug tracker. Haas: cycle of work is different for open items. No, will use wiki instead. Next year we'll have an open items app.<br />
<br />
Doing early branching will also help with bitrot. And will help with people's work schedules.<br />
<br />
Plan is to start 9.1 development on July 15, and only delay if things blow up.<br />
<br />
Alpha releases unanimously good. We might want to branch them differently. Downloads weren't huge, 10s or maybe 100 per alpha. But practice found issues with packaging, build scripts, etc. Maybe we shouldn't create branches for them, though. We should just tag it. We just wanted it to say the right name. This is probably fixed. So, for 9.1 we'll have a patch for the tarball and not a branch. Discussion of checkout/tag/branch detailed ensued.<br />
<br />
CFs need to have enough reviewers. Need to recruit more? Need to make it clear what's in it for reviewers. Reviewers should be nominated for minor contributors.<br />
<br />
Actions: <br />
* Selena to get reviewers to start now.<br />
* Branch on July 1, CF July 15.<br />
* Announce as plan for schedule.<br />
* No more branching for alphas.<br />
<br />
== Performance QA/Performance Farm ==<br />
<br />
Last year we took this as an issue at the meeting. Holdup was pgBench needed overhaul; results were useless on Linux. New pgBench should resolve those problems. Got something in pgBench tools which tries to figure out number of threads. Other thing which has been moving along well is benchfarm, and how should systems be set up to give reasonable performance. Greenplum has nice utility called gperftest, people need to test hardware before running pgbench. Nobody will let us benchmark high-end machines and talk about the results. Smith has some new high-end machines to test performance results.<br />
<br />
Smith: we are ready to write a spec for a performancefarm client. Need to build client for this. Frost has an intern to work on Postgres stuff will be working on performance farm client. Will be working for 8 weeks.<br />
<br />
Performancefarm also needs to run a battery of individual operations for performance regressions. Also needs to run a quick hardware/OS test for comparability. Need a general framework; maybe we'll eventually add DW test or TPCH. <br />
<br />
Why do we keep the same dependancy restrictions as buildfarm? It's easier to get clients that way. If we can tell people that they can just add the PerformanceFarm to the buildfarm, it's easier. Will go to assembled tool very soon. Data collection will start with 9.0 because of old pgbench. Biggest thing is to notice if someone's patch torpedoes performance.<br />
<br />
Propose that machines for the PerformanceFarm be named after plants. ;-)<br />
<br />
What about replication performance? Too big to take over.<br />
<br />
Actions: Stephen's intern to develop PerformanceFarm application. Will need help from Dunstan/Drake etc.<br />
<br />
== Advanced Security Features ==<br />
<br />
KaiGai's Presentation <link?><br />
<br />
We try to load something externally to make access control decisions. Row-level access controls have a number of issues. <br />
<br />
PostgreSQL currently has logic & access controls in the same place. (1) rework external check using same flow. (2) add label support. (3) add SELinux support. New method will have clear separation between Postgres and SELinux, possibly using a loadable module. <br />
<br />
Rework of access controls needs to do all of the access control checks at once instead of one at a time with query in between. Need to do one object at a time because otherwise it's too big. That way patches are only 200-500 lines each.<br />
<br />
Finally, add security labels to objects.<br />
<br />
The concern with the rework was that moving all of the security checks into a separate area was that that area needed to have knowledge about everything. Haas: need to provide a clean interface to security providers, but not by changing huge amounts of code. Heikki: it's not that big, it's fairly mechanical. <br />
<br />
Currently we check some basic things (like does the table exist) and later we check fine-grained permissions. Completely isolating it not possible. Locks for one thing. Also it's difficult to have a clean API because the API needs to know about everything. Kaigai says that generalized interface isn't necessary, Linux has had to add to the API with each new security provider.<br />
<br />
Why can't we put calls in the current aclcheck? Too low-level, don't pass enough information to them. We could pass more. But if we have the OID, we can look up all of the class information. Right now we have duplicate permissions checks all over the code. And the checks we need to do are not necessarily the same checks which SE wants to do.<br />
<br />
Smith: what users want isn't necessarily what we have in the patch. Maybe we should just build a subset of functionality, a lot of people don't care about DDL etc. We could implement only SELECT security, it would make the patch more digestible. All permissions checks for SELECT are all in one place. Or DML only.<br />
<br />
Does the information provided supply enough? It has to be because it's the first stage. It's basically the information the user entered. <br />
<br />
Is DML-only enough? Will it leak? Of course. Anyway, it's useful simplication. Smith says 95% of use cases are solved by that. Table discussion of all of the ACL checks. Kaigai says that checks are the same for DML and DDL, but others do not agree.<br />
<br />
Security Label discussion. Access control decisions operated by Subject, Target, Action. Label replaces Target. Syntax introduced, ALTER ... SET WITH SECURITY LABEL, SECURITY LABEL TO label. Simplified suggestion, just add seclabel[] text to catalogs. But wastes space and hurts peformance. <br />
<br />
Should SELinux be in core or be loadable module? <br />
<br />
Actions: Kaigai, Stephen, Smith, etc. to get together at pgCon and hash out some more issues.<br />
<br />
== CVS to GIT ==<br />
<br />
Its probably clear that we should change to a new VCS, and it should be GIT. No disagreement. <br />
<br />
What are the gating factors to moving now? Let's make a decision to do it, and when and we'll fix the issues. Problem with buildfarm has been solved. Buildfarm now runs git. Building Git on any older platform is impossible; bad make files. Getting all buildfarm members running Git wouldn't be possible, but we can run CVS mirror for older ones.<br />
<br />
We have a checklist on the wiki already for switching.<br />
<br />
Most buildfarm members will run either; it's a config item. We'll track which ones are using the emulator. <br />
<br />
Building older versions may have issues to build identically. Magnus claims that it's been fixed. How much do we care about old tags? There are still a couple of bad files but they're minor. Do we still have old issues with CVS? Marc says they're fixed, shouldn't show up in Git history.<br />
<br />
Are commit e-mails an issue? No. But e-mails will look different. Tom wants them to just work the same. <br />
<br />
We don't need to solve technical issues here. Just pick a date. We'll know when we're doing it and that everything will suck for a month afterwards. Will need to be a low-stress time for the project, between commitfests. Tom isn't sure how to apply commits across multiple branches. Discussion of Git details hashed out.<br />
<br />
Two issues: sheer space usage. Second, management of commits. But these are not serious problems. Andrew has checklist. Will need to test stuff and decide how to do specific stuff. Suggestion on date: after 2nd commitfest. No, halfway after first commitfest. No, immediately after first commitfest ... August 20th or similar.<br />
<br />
We will have git super-master which synchs to git.postgresql.org. Can do receive hooks. Have we considered using github? Github should not be canonical source, in case they go away. Can't do postcommit hooks on Github. People can just do both. Forking Postgres repo puts you near their limit. Put off Github questions.<br />
<br />
Issue: what about the name? People will need to reclone, will be part of suckitude. Rename old repo and create new repo. Where will secret master repo be? Maybe Conova.<br />
<br />
Mapping usernames onto e-mail addresses could be a pain. Maybe we should standardized onto committer@postgresql.org. Committers should pick names before conversion.<br />
<br />
Discussion about commit messages, merges, commits, etc. ensued.<br />
<br />
Action: <br />
* Magnus to set up emulator.<br />
* Andrew to publish checklist of how to set up your Git<br />
* Move to Git August 17-20: Magnus, Haas, Dunstan. Frost will be out.<br />
<br />
== Lunch ==<br />
<br />
== Clustering ==<br />
<br />
=== Snapshot Cloning ===<br />
<br />
Koichi: had meeting in Tokyo, and make a list of core APIs which clustering projects could use. Snapshot cloning is one such, plus it's useful for parallel query and parallel pg_dump. First use snapshot cloning to enforce consistent view of the database. Has already implemented this for PostgresXC. The same thing could be applicable for single PostgreSQL. It is a very simple implementation, and should not produce resource conflicts.<br />
<br />
For parallel pg_restore, maybe snapshot cloning will not be sufficient. Cloning the snapshot for read-only transactions is simple, not for write transactions. <br />
<br />
Smith: Using this for parallel query also works for read-only cloning.<br />
<br />
Very useful for dumping partitioned tables, with one backend for each partition. <br />
<br />
Added API to libpq. But shouldn't this be a server-side command? For cluster usage, it was useful for it to be in libpq. RH: one idea is a function we could call, and the shared snapshot would use a "cookie". Joachim W. wrote a patch with publish/subscribe. Needs to be all server-side. <br />
<br />
Tom has suggestion for simpler implementation, without locks. That is, you just need to have same snapshot start, not shared snapshot. Snapshot would die once the original transaction was gone. Koichi: this is not a problem.<br />
<br />
Tom: maybe we could just use a prepared transaction, which would keep the snapshot valid. Proposing to begin with read-only implementation.<br />
<br />
Action: Koichi to extract patch from PostgresXC and submit.<br />
<br />
== XID Feed ==<br />
<br />
PostgresXC needs to have a transaction run on multiple servers in the same cluster. The XID is needed so that you can have the same transactions. Will also be useful for parallel write operation, but that's really complicated. Parallel backend needs to be assigned same XID, but locks, resource conflicts.<br />
<br />
Heikki: let's start with parallel read queries.<br />
<br />
JB: parallel write on one server is a different feature than XID feed for clustering.<br />
<br />
Multiple backends share the same XID so they can share the same snapshot. If you're doing a multimaster update across multiple servers so you can maintain serialization. Stark explains multi-server deadlock situation.<br />
<br />
The XID is not the issue, it's the commit order. But communicating the xids means that you don't need to communicate more data to the servers. Just maintaining transaction IDs isn't enough, we need to maintain commit/abort info. If you want a snapshot which is valid on both nodes, you'd have to lock the procarray on both. You'd have to have a single global transaction manager controlling commits.<br />
<br />
What is the core feature here? You might want to make a specific instance of Postgres the global transaction manager. Or you might make one postgres a consumer of snapshots. Heikki: you could interrogate each node about what transactions were running at the time of the snapshot. Some discussion without agreement.<br />
<br />
Koichi explains how snapshots are distributed in PostgresXC, they receive them with XID. There's no negotiation between nodes. What stability would this affect with core Postgres? Vacuum and analyze need their own GXID. <br />
<br />
What is the feature: getting XID and Snapshot from PostgreSQL. Is this useful for core Postgres? Does it work for other cluster systems other than PostgresXC. Would be useful for all synchronous multi-master replication. Like Postgres-R. Or any distributed databases. Should be done as a "hook". Not really different from two-phase commit, but not testable without an external manager, which is the main problem. How could you test it?<br />
<br />
What other things do you need? What other hooks would we need in core to support GTM and other clustering functionality? If we had SQL/MED working, you could export XIDs to remote tables. But we don't have that yet.<br />
<br />
A hook will be fine.<br />
<br />
Action: Koichi to come up with proposed patch design<br />
<br />
=== General Modification Queue ===<br />
<br />
Marko: one use case is transactional que. Have some sample imentations in pgQ and Slony. Two different stragies: Slony/Londiste, and Josh wants to replicate data to external non-PostgreSQL tables. Josh is mainly concerned about write overhead, but no way around WAL.<br />
<br />
What is not solved by current LISTEN/NOTIFY? What this has is potential for really improving. Both Slony and pgQ rely on being able to filter out blocks of events and serialized sequence of individual events. Problem is eventID sequence number cannot be cached, that causes painful overhead. Both systems come up with insert/update/delete statements which go by index scan.<br />
<br />
If we can support general functions where a trigger can hand in old and new tuples and the receiver can get something which allows it to pull new data. Seems like commit order is the issue. Why do you need a sequence which can't be cached? If you knew what order they committed ... you wouldn't need a global counter. Jan isn't sure this makes sense for core because of lack of version independance.<br />
<br />
If you had a stream of commit information, you'd just have to buffer it. But that could work. The real missing piece is a commit ordering stamp, which the database should supply for you. This was a requirement of Postgres-R as well, they need to know what order to apply the writeset in.<br />
<br />
We could use the LSN of the commit record as that number. In the CLOG, for a range of XIDs, we have some LSNs. But it's not enough information. It sounds like all that's really needed is to have a way to grab LSN numbers. Maybe write it to a separate file.<br />
<br />
Commit-order table would need to be truncated. The clients have to send message about being done with it. Do we want to call gettimeofday while holding walinsertlock? Tom: we already are, but it's not exact enough. LSN plus approximate timestamp would give you order.<br />
<br />
Clients would need to look and say grab all transactions between one LSN and another.<br />
<br />
Action:<br />
* Develop specification for commit sequence / LSN data<br />
<br />
=== DDL Triggers ===<br />
<br />
Jan: it's a feature we've been missing for at least a decade. Jan starting to work on it, but DDL code is very messy. It's in tcop_utility.c function process_utility. The mess is that while the function gets a query string some calls don't put a real query string in there. <br />
<br />
Purposes include enforcement of complex CREATE requirements. Also replicating DDL to replicas. Wouldn't you like it better if the data were passed to the trigger using some kind of structured data rather than a query string. Take node structure of utility statement and create query string which can be passed, as well as passing node structure using nodetostring.<br />
<br />
We haven't exposed nodetostring because it's not a stable API. But generally changes there indicate changes in features. But if we could give the trigger an object name. Maybe we could pass before-and-after snapshots.<br />
<br />
How do Oracle and other systems get this data?<br />
<br />
Also there's an issue that some utility statements call other utility statements. <br />
<br />
Nodetostring exposure was also vetoed for other reasons. Slony and other systems can take a tree instead. Maybe we should already have a utility function. We already theoretically have a hook, but it's not being used. And also still a problem with recursive calls.<br />
<br />
pgAdmin wants a notification for changes. Would need some notification with data about object changed. But just object changed would be enough. We could also build up a set of events for DDL changes over time based on the tree ... we can start with just objectype and objectID. And type of modification: create, drop, alter.<br />
<br />
ProcessUtilityHook is there, but the problem is how it's exposed to the user. Hooks aren't used consistently and you don't know who has set it in what modules. Several people are already using it. Ordering becomes a problem. People don't want to use the hook.<br />
<br />
We also want a userspace implementation. Like maybe a trigger.<br />
<br />
Action:<br />
* Wiki page to be updated with spec by Jan et. all.<br />
<br />
== Status Report on Modules ==<br />
<br />
Slides from Dimitri<br />
<br />
Many issues and topics. Talking today about dump/reload support. If you dump and restore, you don't want to restore objects. We want to support any source language. We want to support custom GUCs and versions in extensions. We also want upgrading factilities.<br />
<br />
We are not going to talk about schema. We are not going to talk about souce level packaging, ACLs, PGAN or OS packaging and distribution. Example of extensions/foo/control. Should be in user/share. Control file will have name, version, custom_variable_classes.<br />
<br />
Then you can just do install extension foo, drop extension foo. pg_restore would call install extension foo and not its objects.<br />
<br />
Need dependancies on extensionID in pg_depends so we know what belongs to the extension.<br />
<br />
Used name = value because we already know how to parse them in control file. pg_dump will be easy, we will know how to exclude based on dependancies. uninstall.sql files will be replaced by this. <br />
<br />
What do we do about user-modifiable tables which are associated with a module? This is similar to how debian deals with config files. Or we could allow install files have items which aren't tracked as part of the module, and pg_restore would need to know about that.<br />
<br />
Should extensions have different versions or different names per version? The install script is just a sql file, you can add a DO script. Debian handles this by checking if the configuration is the default and replacing it, or failing over to the user afterwards. <br />
<br />
Need license information in the control file.<br />
<br />
We probably just need to punt configuration tables to version 2.<br />
<br />
Will this help pg_upgrade? Maybe. Right now you have to migrate shared libs yourself. Will fix some cases.<br />
<br />
Action:<br />
* Dimitri to do patch<br />
<br />
== SQL/MED ==<br />
<br />
Slides by Heikki.<br />
<br />
Heikki: in EDBAS, we already have foriegn tables. CREATE FOREIGN TABLES syntax. EDB has libpq, Oracle and ODBC. Shows slide with join plan; currently materialize locally.<br />
<br />
Have to decide what plans you can push to the remote database. Not all remote sources can handle all structures, including functions, joins etc. Even between PostgreSQL ruleutils.c is different for each version.<br />
<br />
Proposed FDW planner API. Pass parse tree, needs to say what it can take. How do we not duplicate the entire planner in the API. EnterpriseDB has been working on this but company has not committed to contributing it.<br />
<br />
Jan mentioned that at least a wrapper has to take a scan. <br />
<br />
Itagaki: didn't know EDB was also working on SQL/MED. Code is probably completely different. There's four issues: any features it should consider about. Currently considering dbLink and COPY FROM. Maybe there should be other features, like GDQ. <br />
<br />
Josh: what about PL/proxy? SQL/MED should support the functionality of PL/proxy. <br />
<br />
What is the best design to support access methods for tables? Postgres AMs for indexes, we need AMs for FDWs. Update is a problem, may start with select and insert.<br />
<br />
How to push WHERE conditions to FDW? Itagaki's WIP code uses internal tree, requires C code in FDW to parse. Might be unstable for that reason. External server might not be SQL server, so passing SQL isn't that useful.<br />
<br />
FDW vs. SRF ... can we merge these somehow? Current implementation of functionscan is to materialize. We didn't do value-per-call because it was difficult with PL/pgSQL. So we just materialized it.<br />
<br />
Heikki suggested that we don't use the FDW API from the SQL committee because nobody uses it. Supplies function for reaching into planner but can't imagine how it would work. EnterpriseDB implements pipeline.<br />
<br />
Also, an issue is cost estimation. How do we know how much it would cost. Statistics on remote tables? We could store them. It would also be nice to have joins take place on the remote server, but that's version 2 or 3. <br />
<br />
Also what about indexes on the remote server. One implementation in Japan has CREATE FOREIGN INDEX. Creating definitions locally of remote schema are very useful. DB2 implemented this and had commands to define foreign objects.<br />
<br />
Maybe we don't need to be really smart about this in the first version. But people are asking for this. Pass whole query to remote server. Wouldn't work for joins, but would work for union query. Defining an index on a FDW doesn't make much sense since we don't know what the costs are like over there. We should just have a function in the API.<br />
<br />
How would we recognize that we want to do the join on the remote server. We just need costs from the FDW. But we could also keep them in pg_stats. FDW might be used to access complex database like Infobright or Bigtable. <br />
<br />
Would EDB contribute a patch? Or just the rights for Heikki to steal bits? Patch from EDBAS would not work. Does the EDB patch help Itatgaki? EDB might get Itagaki access to the code.<br />
<br />
Action:<br />
* EDB to decide on opening code or not<br />
* Review Itagaki's git repo code: Heikki, Peter<br />
* Itagaki to keep working on API -- what about Peter?<br />
<br />
== pg_migrator ==<br />
<br />
Bruce: Just fixed a but in pg_upgrade for XID wraparound. Added docs. Migrator tries to rebuild a plane in the air. Bruce feels like he has a swiss army knife with pg_upgrade. Issue with FrozenXIDs in template0 fixed. Still a work in progress, which is why it's in contrib, still a work in progress but bugs are fixable.<br />
<br />
Will still have issues with page format, binary format changes. Haven't had those for a while, may not need them, and a dump & restore every 4-5 years is an improvement. Bunches of people have used it to migrate. The tool makes sure that it doesn't corrupt your data, it goes back if it hits an error.<br />
<br />
Stark: In the past we've had a chicken-and-egg issue if people wanted to make changes to the data format, we'd need a conversion function. And there's no hooks in pg_migrator. Could slow down the pace of adding features. We should add the functionality to do the conversion now.<br />
<br />
pg_upgrade from EDB has hook for COPY mode for conversion. And then what's the point of pg_migrator? If you don't have to rebuild indexes. But a lot of times you'd have to. But to have it in place so that it's not a hurdle for a data change. If we're going to do that we need to do it for 9.1 early in the cycle.<br />
<br />
Dump and reload is impossible for Smith's customers. page checksum thing is a good example. Read-on-conversion is a big performance hit. Background process to convert all old data. <br />
<br />
Also issue around internal representation of data type change. We either have to convert it, or have versioned data types.<br />
<br />
Is binary data conversion really faster? Read back one version, and convert while running. Something which can read one version level back and can convert is the only viable way. Would have a daemon to convert data. What about split pages, bigger page headers.<br />
<br />
CRC would be a good test for this. It's a small patch but has a lot of common upgrade issues. And it would be only one patch so we could put it off for another version if we had to. Would like to get this started for 9.1. CRC requires dealing with the split pages issue.<br />
<br />
Really tricky stuff includes changing indexing structure. Would need concurrent rebuild for unique indexes and primary keys. REINDEX concurrently was a deadlock concern. <br />
<br />
What about writing? Convert-on-read. <br />
<br />
Action:<br />
* Document what the plan is to do a conversion upgrade (Greg Smith)<br />
* Copy Zdenek's code (Greg Smith)<br />
<br />
== Other Business ==<br />
<br />
Treat: Mammoth Replicator into Core? Code has been BSD-licensed. Has features which don't exist in Hot Standby. Code is pretty big. Alvaro would say that it's not in great shape to contribute at this point.<br />
<br />
Has log-based replication including per-table. Has its own logs, and has binary vs. SQL replay. Not trigger-based. <br />
<br />
Real question is would we consider putting any replication solution into Core? Not until we've finished digesting HS/SR. Replication is one word for a dozen different solutions for 3 dozen problems. We've accepted one which solves some problems. Page things we should consider each case on its merits.<br />
<br />
Question is what parts of Mammoth make sense to be in core. Bruce thinks that mammoth is so tied into the backend that we couldn't accept it. It's too complicated. It doesn't sound like Mammoth offers enough functionality to make it worth it.<br />
<br />
Does mammoth need to be in core? It has grammar changes. We now have better ideas of what replication requirements are, we may have more commonalities in core in the future. Part of the reason have so many because we don't have one in Core.<br />
<br />
We'd consider more replication in core, but maybe not Mammoth.<br />
<br />
Action:<br />
* None<br />
<br />
== Other Business ==<br />
<br />
Peter says we're almost compliant with SQL 2008. Is it of PR value to comply with the remaining random stuff? People don't think so. <br />
<br />
What about Case Folding? We probably don't want to fix that. Wasn't on Peter's list, which is just features. Case Folding would break a lot of stuff. Thought Peter was already doing that with a couple of features per version.<br />
<br />
Compliance is only of moderate value. Is there a point of implementing the features on Peter's list?<br />
<br />
Summer of Code: how is it going?<br />
<br />
Haas has concern. His student is working on Materialized Views. Has proposed a very basic implementation. Might not be able to do even that. We can fail people.<br />
<br />
Selena just updated the open items on the mailing list. A lot of items were not closed on the mailing list.<br />
<br />
What about max_standby_delay? Tom wants to go back to just a boolean. What about Tom's original proposal? Can't really do it. Tom wants to remove time dependancy. What are the issues with max_standby_delay? Idle time on the master uses up time on the standby. Plus NTP and keepalives and some other stuff.<br />
<br />
Major discussion on max_standby_delay ensued.<br />
<br />
== Development Priorities for 9.1 ==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Feature<br />
!Developers<br />
!Notes<br />
|-<br />
|MERGE/UPSERT/REPLACE<br />
|GSoC with Greg Smith/Simon<br />
|Issues with predicate locking<br />
|-<br />
|Synchronous replication<br />
|Fujii/Zoltan/Simon<br />
|Review by Heikki<br />
|-<br />
|Improve Hot Standby/Streaming Rep usability<br />
|Simon/Fujii/Greg Smith<br />
|Review by Josh Berkus<br />
|-<br />
|Snapshot cloning API<br />
|Koichi<br />
|Sample app is parallel pg_dump<br />
|-<br />
|Locale/encoding <br />
|<br />
|per column/per operator collation<br />
|-<br />
|User exposed predicate locking<br />
|Simon<br />
|Interaction with serialization<br />
|-<br />
|[[Serializable]]<br />
|Kevin Grittner/Dan Ports<br />
|<br />
|-<br />
|pg_upgrade in core<br />
|Bruce<br />
|<br />
|-<br />
|External security provider<br />
|KaiGai<br />
|<br />
|-<br />
|Row-level security<br />
|KaiGai<br />
|<br />
|-<br />
|Writeable CTEs<br />
|Marko Tiikkaja <br />
|<br />
|-<br />
|SQL/MED<br />
|Itagaki<br />
|<br />
|-<br />
|Generalized inner-indexscan plans<br />
|Tom Lane<br />
|<br />
|-<br />
|Re(?)plan parameterized plans with actual parameter values<br />
|Tom Lane<br />
|<br />
|-<br />
|COPY as a FROM clause<br />
|Andrew Dunstan<br />
|<br />
|-<br />
|Pipelining/value per call for SRFs<br />
|Joe Conway<br />
|<br />
|-<br />
|Partitioning implementation<br />
|Itagaki<br />
|<br />
|-<br />
|Index only scans<br />
|Heikki<br />
|<br />
|-<br />
|Global temp/unlogged tables<br />
|Robert Haas<br />
|<br />
|-<br />
|Inner join removal<br />
|Robert Haas<br />
|<br />
|-<br />
|Extensions<br />
|Dimitri<br />
|<br />
|-<br />
|Range types<br />
|Jeff Davis<br />
|<br />
|-<br />
|Materialized views<br />
|GSoC+Robert Haas<br />
|<br />
|-<br />
|JSON data type<br />
|GSoC<br />
|<br />
|-<br />
|DDL Triggers<br />
|Jan<br />
|<br />
|-<br />
|Leaky view security<br />
|<br />
|<br />
|-<br />
|KNNGist<br />
|Teodor<br />
|<br />
|-<br />
|Performance farm<br />
|Greg Smith<br />
|<br />
|-<br />
|Git<br />
|<br />
|<br />
|-<br />
|[[PGXN]]<br />
|David Wheeler<br />
|<br />
|}<br />
<br />
<br />
[[Category:PostgreSQL Events]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=11198PGXN2010-06-14T02:56:17Z<p>Theory: Update link to CPAN Meta Spec.</p>
<hr />
<div>This document outlines the specification for the creation of PGXN, the PostgreSQL Extension Network (formerly known as "PGAN"). The purpose of PGXN is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PGXN.<br />
<br />
=Upload Server=<br />
<br />
The models for the upload server include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (upload.pgxn.org), if possible use existing postgresql.org logins. From there, users can upload release packages to the site and add or delete release managers.<br />
<br />
Once a package is uploaded, it is considered released and its name registered to the uploading user. The upload server will add its metadata to its database and add the package and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PGXN. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via the upload server.<br />
<br />
The upload server will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to the upload server as Gzip-, Bzip2-, or Zip-compressed packages. The upload server will unpack it, validate its contents, and repack it with Zip compression into a file ending with <code>.pgz</code>. A distribution package is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PGXN Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://search.cpan.org/perldoc?CPAN::Meta::Spec CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PGXN. The names "PostgreSQL", "Postgres", "pgsql", and "psql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed, defined one of a set of predefined strings, a URL, or a structure identifying the license name and URL.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>: This is the standard [http://www.postgresql.org/docs/current/static/xfunc-c.html#XFUNC-C-PGXS PGXS] build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>: The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>: May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>: Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>: Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>: Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PGXN Directory=<br />
<br />
The entire directory of PGXN will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PGXN for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PGXN database and listed on the PGXN Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PGXN will contain information about all the distributions on PGXN, including relevant metadata. It will also include information about registered PGXN users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow visitors to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from the upload server hourly, and will include a feed of recent releases uploaded to PGXN. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PGXN to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PGXN Client=<br />
<br />
The PGXN client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN] and [http://search.cpan.org/perldoc?cpanminus cpanminus] clients. Essentially, it will provide an interface to easily download, build, test, and install PGXN distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN clients.<br />
<br />
For the initial implementation, the PGXN client will assume that extensions can be built using [http://www.postgresql.org/docs/current/static/xfunc-c.html#XFUNC-C-PGXS PGXS] with:<br />
<br />
<pre>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</pre><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PGXN client will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PGXN client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. To the extent that PGXS-powered <code>make</code> works on a given platform, the client will support it.<br />
<br />
The PGXN client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PGXN index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PGXN is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PGXN infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PGXN=<br />
<br />
Once the initial implementation of PGXN is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution package ready for release on PGXN.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the package, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PGXN RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PGXN extensions.<br />
* PGXN Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PGXN?''' Open-source PostgreSQL extension release packages. The current contrib extensions serve as the model for the contents of such packages. Following the [http://www.cpan.org/misc/ZCAN.html CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PGXN?''' Non-package files (that is, files that are not tarballs, bzip-balls, or zip archives), closed-source distributions, and distributions with no license.<br />
* '''Who can release on PGXN?''' Any registered user.<br />
* '''Who can register for PGXN?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PGXN needs to [http://en.wikipedia.org/wiki/KISS_principle KISS]. Longer answer: No. Again following the [http://www.cpan.org/misc/ZCAN.html CPAN example], PGXN "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of PGXN is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL. PGXN will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting. The only thing in common with pgFoundry is uploading release packages. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PGXN client will be updated to take advantage of new features. Such improvements are expected to make PGXN more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PGXN.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PGXN will take advantage of them, but none are required in order to bootstrap PGXN.<br />
* '''How will PGXN make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PGXN with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PGXN client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves such that a compiler is no longer required, the PGXN client will be modified as appropriate to take advantage of it. This applies not specifically to Windows, but to the ability of the core installer (or any future community-supported installer) to work on ''any'' platform.<br />
* '''What kind of security will it have?''' Each release package will have an accompanying SHA1 hash that the PGXN client will verify before installing an extension.<br />
<br />
=References=<br />
* [http://www.cpan.org/misc/ZCAN.html The Zen of Comprehensive Archive Networks]<br />
* [http://use.perl.org/comments.pl?sid=9630&cid=14713 Easier than you think] (comment on ZCAN)<br />
* [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod The CPAN Meta spec]<br />
* [http://wiki.postgresql.org/wiki/ExtensionPackaging PostgreSQL Extensions Proposal]<br />
* [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]<br />
* [http://trac.parrot.org/parrot/wiki/ModuleEcosystem The Parrot Module Ecosystem]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=11129PGXN2010-06-03T16:52:50Z<p>Theory: s/PgDEX/PGXN/g</p>
<hr />
<div>This document outlines the specification for the creation of PGXN, the PostgreSQL Extension Network (formerly known as "PGAN"). The purpose of PGXN is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PGXN.<br />
<br />
=Upload Server=<br />
<br />
The models for the upload server include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (upload.pgxn.org), if possible use existing postgresql.org logins. From there, users can upload release packages to the site and add or delete release managers.<br />
<br />
Once a package is uploaded, it is considered released and its name registered to the uploading user. The upload server will add its metadata to its database and add the package and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PGXN. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via the upload server.<br />
<br />
The upload server will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to the upload server as Gzip-, Bzip2-, or Zip-compressed packages. The upload server will unpack it, validate its contents, and repack it with Zip compression into a file ending with <code>.pgz</code>. A distribution package is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PGXN Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PGXN. The names "PostgreSQL", "Postgres", "pgsql", and "psql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed, defined one of a set of predefined strings, a URL, or a structure identifying the license name and URL.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>: This is the standard [http://www.postgresql.org/docs/current/static/xfunc-c.html#XFUNC-C-PGXS PGXS] build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>: The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>: May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>: Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>: Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>: Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PGXN Directory=<br />
<br />
The entire directory of PGXN will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PGXN for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PGXN database and listed on the PGXN Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PGXN will contain information about all the distributions on PGXN, including relevant metadata. It will also include information about registered PGXN users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow visitors to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from the upload server hourly, and will include a feed of recent releases uploaded to PGXN. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PGXN to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PGXN Client=<br />
<br />
The PGXN client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN] and [http://search.cpan.org/perldoc?cpanminus cpanminus] clients. Essentially, it will provide an interface to easily download, build, test, and install PGXN distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN clients.<br />
<br />
For the initial implementation, the PGXN client will assume that extensions can be built using [http://www.postgresql.org/docs/current/static/xfunc-c.html#XFUNC-C-PGXS PGXS] with:<br />
<br />
<pre>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</pre><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PGXN client will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PGXN client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. To the extent that PGXS-powered <code>make</code> works on a given platform, the client will support it.<br />
<br />
The PGXN client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PGXN index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PGXN is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PGXN infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PGXN=<br />
<br />
Once the initial implementation of PGXN is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution package ready for release on PGXN.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the package, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PGXN RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PGXN extensions.<br />
* PGXN Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PGXN?''' Open-source PostgreSQL extension release packages. The current contrib extensions serve as the model for the contents of such packages. Following the [http://www.cpan.org/misc/ZCAN.html CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PGXN?''' Non-package files (that is, files that are not tarballs, bzip-balls, or zip archives), closed-source distributions, and distributions with no license.<br />
* '''Who can release on PGXN?''' Any registered user.<br />
* '''Who can register for PGXN?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PGXN needs to [http://en.wikipedia.org/wiki/KISS_principle KISS]. Longer answer: No. Again following the [http://www.cpan.org/misc/ZCAN.html CPAN example], PGXN "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of PGXN is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL. PGXN will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting. The only thing in common with pgFoundry is uploading release packages. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PGXN client will be updated to take advantage of new features. Such improvements are expected to make PGXN more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PGXN.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PGXN will take advantage of them, but none are required in order to bootstrap PGXN.<br />
* '''How will PGXN make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PGXN with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PGXN client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves such that a compiler is no longer required, the PGXN client will be modified as appropriate to take advantage of it. This applies not specifically to Windows, but to the ability of the core installer (or any future community-supported installer) to work on ''any'' platform.<br />
* '''What kind of security will it have?''' Each release package will have an accompanying SHA1 hash that the PGXN client will verify before installing an extension.<br />
<br />
=References=<br />
* [http://www.cpan.org/misc/ZCAN.html The Zen of Comprehensive Archive Networks]<br />
* [http://use.perl.org/comments.pl?sid=9630&cid=14713 Easier than you think] (comment on ZCAN)<br />
* [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod The CPAN Meta spec]<br />
* [http://wiki.postgresql.org/wiki/ExtensionPackaging PostgreSQL Extensions Proposal]<br />
* [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]<br />
* [http://trac.parrot.org/parrot/wiki/ModuleEcosystem The Parrot Module Ecosystem]</div>Theoryhttps://wiki.postgresql.org/index.php?title=Talk:PgDEX&diff=11128Talk:PgDEX2010-06-03T16:51:03Z<p>Theory: Talk:PgDEX moved to Talk:PGXN: New name, much better.</p>
<hr />
<div>#REDIRECT [[Talk:PGXN]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=Talk:PGXN&diff=11127Talk:PGXN2010-06-03T16:51:03Z<p>Theory: Talk:PgDEX moved to Talk:PGXN: New name, much better.</p>
<hr />
<div>== Possible FAQ Addition ==<br />
<br />
How to pronounce PGAN? (P-G-An, P-Gan?)<br />
<br />
== PgFoundry considered useful ==<br />
<br />
Why not use PgFoundry as a place for uploading extensions?<br />
<br />
It already provides many facilities needed for development<br />
and is being quite used. Developers can already neatly package<br />
and upload their stuff. It already supports versioned file distribution.<br />
It is just not well enough integrated with actual running database one<br />
is using in practice.<br />
<br />
PgDEX could periodically (say once a day) download all changed<br />
published .tar.gz files (but not stuff in SCM) and compile<br />
them into installable packages. These would be installed by<br />
special command line utility, as suggested.<br />
<br />
What seems to be needed with this is a way to specify meta-information<br />
in packages; this could be in a form of a required file (say control,<br />
control.xml or pg_package.xml), which would contain the required data.<br />
Perhaps XML and/or RDF would be a good choice for this?<br />
<br />
At the very least, it would seem sensible to have some kind of correspondence<br />
between extension names and PgFoundry projects.<br />
<br />
--[[User:Ziga|Ziga]] 18:11, 27 May 2010 (UTC)</div>Theoryhttps://wiki.postgresql.org/index.php?title=PgDEX&diff=11126PgDEX2010-06-03T16:51:03Z<p>Theory: PgDEX moved to PGXN: New name, much better.</p>
<hr />
<div>#REDIRECT [[PGXN]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=11125PGXN2010-06-03T16:51:03Z<p>Theory: PgDEX moved to PGXN: New name, much better.</p>
<hr />
<div>This document outlines the specification for the creation of PgDEX, the PostgreSQL Distributed Extension Network (formerly known as "PGAN"). The purpose of PgDEX is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PgDEX.<br />
<br />
=Upload Server=<br />
<br />
The models for the upload server include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (upload.pgdex.net), if possible use existing postgresql.org logins. From there, users can upload release packages to the site and add or delete release managers.<br />
<br />
Once a package is uploaded, it is considered released and its name registered to the uploading user. The upload server will add its metadata to its database and add the package and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PgDEX. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via the upload server.<br />
<br />
The upload server will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to the upload server as Gzip-, Bzip2-, or Zip-compressed packages. The upload server will unpack it, validate its contents, and repack it with Zip compression into a file ending with <code>.pgz</code>. A distribution package is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PgDEX Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PgDEX. The names "PostgreSQL", "Postgres", "pgsql", and "psql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed, defined one of a set of predefined strings, a URL, or a structure identifying the license name and URL.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>: This is the standard [http://www.postgresql.org/docs/current/static/xfunc-c.html#XFUNC-C-PGXS PGXS] build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>: The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>: May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>: Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>: Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>: Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PgDEX Directory=<br />
<br />
The entire directory of PgDEX will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PgDEX for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PgDEX database and listed on the PgDEX Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PgDEX will contain information about all the distributions on PgDEX, including relevant metadata. It will also include information about registered PgDEX users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow visitors to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from the upload server hourly, and will include a feed of recent releases uploaded to PgDEX. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PgDEX to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PgDEX Client=<br />
<br />
The PgDEX client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN] and [http://search.cpan.org/perldoc?cpanminus cpanminus] clients. Essentially, it will provide an interface to easily download, build, test, and install PgDEX distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN clients.<br />
<br />
For the initial implementation, the PgDEX client will assume that extensions can be built using [http://www.postgresql.org/docs/current/static/xfunc-c.html#XFUNC-C-PGXS PGXS] with:<br />
<br />
<pre>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</pre><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PgDEX client will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PgDEX client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. To the extent that PGXS-powered <code>make</code> works on a given platform, the client will support it.<br />
<br />
The PgDEX client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PgDEX index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PgDEX is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PgDEX infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PgDEX=<br />
<br />
Once the initial implementation of PgDEX is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution package ready for release on PgDEX.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the package, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PgDEX RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PgDEX extensions.<br />
* PgDEX Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PgDEX?''' Open-source PostgreSQL extension release packages. The current contrib extensions serve as the model for the contents of such packages. Following the [http://www.cpan.org/misc/ZCAN.html CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PgDEX?''' Non-package files (that is, files that are not tarballs, bzip-balls, or zip archives), closed-source distributions, and distributions with no license.<br />
* '''Who can release on PgDEX?''' Any registered user.<br />
* '''Who can register for PgDEX?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PgDEX needs to [http://en.wikipedia.org/wiki/KISS_principle KISS]. Longer answer: No. Again following the [http://www.cpan.org/misc/ZCAN.html CPAN example], PgDEX "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of PgDEX is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL. PgDEX will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting. The only thing in common with pgFoundry is uploading release packages. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PgDEX client will be updated to take advantage of new features. Such improvements are expected to make PgDEX more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PgDEX.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PgDEX will take advantage of them, but none are required in order to bootstrap PgDEX.<br />
* '''How will PgDEX make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PgDEX with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PgDEX client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves such that a compiler is no longer required, the PgDEX client will be modified as appropriate to take advantage of it. This applies not specifically to Windows, but to the ability of the core installer (or any future community-supported installer) to work on ''any'' platform.<br />
* '''What kind of security will it have?''' Each release package will have an accompanying SHA1 hash that the PgDEX client will verify before installing an extension.<br />
<br />
=References=<br />
* [http://www.cpan.org/misc/ZCAN.html The Zen of Comprehensive Archive Networks]<br />
* [http://use.perl.org/comments.pl?sid=9630&cid=14713 Easier than you think] (comment on ZCAN)<br />
* [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod The CPAN Meta spec]<br />
* [http://wiki.postgresql.org/wiki/ExtensionPackaging PostgreSQL Extensions Proposal]<br />
* [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]<br />
* [http://trac.parrot.org/parrot/wiki/ModuleEcosystem The Parrot Module Ecosystem]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=11027PGXN2010-05-27T04:33:11Z<p>Theory: Various updates and edits, especially the name change.</p>
<hr />
<div>This document outlines the specification for the creation of PgDEX, the PostgreSQL Distributed Extension Network (formerly known as "PGAN"). The purpose of PgDEX is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PgDEX.<br />
<br />
=Upload Server=<br />
<br />
The models for the upload server include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (upload.pgdex.net), if possible use existing postgresql.org logins. From there, users can upload release packages to the site and add or delete release managers.<br />
<br />
Once a package is uploaded, it is considered released and its name registered to the uploading user. The upload server will add its metadata to its database and add the package and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PgDEX. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via the upload server.<br />
<br />
The upload server will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to the upload server as Gzip-, Bzip2-, or Zip-compressed packages. The upload server will unpack it, validate its contents, and repack it with Zip compression into a file ending with <code>.pgz</code>. A distribution package is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PgDEX Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PgDEX. The names "PostgreSQL", "Postgres", "pgsql", and "psql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed, defined one of a set of predefined strings, a URL, or a structure identifying the license name and URL.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>: This is the standard [http://www.postgresql.org/docs/current/static/xfunc-c.html#XFUNC-C-PGXS PGXS] build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>: The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>: May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>: Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>: Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>: Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PgDEX Directory=<br />
<br />
The entire directory of PgDEX will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PgDEX for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PgDEX database and listed on the PgDEX Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PgDEX will contain information about all the distributions on PgDEX, including relevant metadata. It will also include information about registered PgDEX users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow visitors to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from the upload server hourly, and will include a feed of recent releases uploaded to PgDEX. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PgDEX to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PgDEX Client=<br />
<br />
The PgDEX client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN] and [http://search.cpan.org/perldoc?cpanminus cpanminus] clients. Essentially, it will provide an interface to easily download, build, test, and install PgDEX distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN clients.<br />
<br />
For the initial implementation, the PgDEX client will assume that extensions can be built using [http://www.postgresql.org/docs/current/static/xfunc-c.html#XFUNC-C-PGXS PGXS] with:<br />
<br />
<pre>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</pre><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PgDEX client will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PgDEX client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. To the extent that PGXS-powered <code>make</code> works on a given platform, the client will support it.<br />
<br />
The PgDEX client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PgDEX index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PgDEX is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PgDEX infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PgDEX=<br />
<br />
Once the initial implementation of PgDEX is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution package ready for release on PgDEX.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the package, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PgDEX RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PgDEX extensions.<br />
* PgDEX Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PgDEX?''' Open-source PostgreSQL extension release packages. The current contrib extensions serve as the model for the contents of such packages. Following the [http://www.cpan.org/misc/ZCAN.html CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PgDEX?''' Non-package files (that is, files that are not tarballs, bzip-balls, or zip archives), closed-source distributions, and distributions with no license.<br />
* '''Who can release on PgDEX?''' Any registered user.<br />
* '''Who can register for PgDEX?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PgDEX needs to [http://en.wikipedia.org/wiki/KISS_principle KISS]. Longer answer: No. Again following the [http://www.cpan.org/misc/ZCAN.html CPAN example], PgDEX "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of PgDEX is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL. PgDEX will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting. The only thing in common with pgFoundry is uploading release packages. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PgDEX client will be updated to take advantage of new features. Such improvements are expected to make PgDEX more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PgDEX.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PgDEX will take advantage of them, but none are required in order to bootstrap PgDEX.<br />
* '''How will PgDEX make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PgDEX with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PgDEX client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves such that a compiler is no longer required, the PgDEX client will be modified as appropriate to take advantage of it. This applies not specifically to Windows, but to the ability of the core installer (or any future community-supported installer) to work on ''any'' platform.<br />
* '''What kind of security will it have?''' Each release package will have an accompanying SHA1 hash that the PgDEX client will verify before installing an extension.<br />
<br />
=References=<br />
* [http://www.cpan.org/misc/ZCAN.html The Zen of Comprehensive Archive Networks]<br />
* [http://use.perl.org/comments.pl?sid=9630&cid=14713 Easier than you think] (comment on ZCAN)<br />
* [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod The CPAN Meta spec]<br />
* [http://wiki.postgresql.org/wiki/ExtensionPackaging PostgreSQL Extensions Proposal]<br />
* [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]<br />
* [http://trac.parrot.org/parrot/wiki/ModuleEcosystem The Parrot Module Ecosystem]</div>Theoryhttps://wiki.postgresql.org/index.php?title=Talk:PGAN&diff=11026Talk:PGAN2010-05-27T04:08:00Z<p>Theory: Talk:PGAN moved to Talk:PgDEX: New name for the project.</p>
<hr />
<div>#REDIRECT [[Talk:PgDEX]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=Talk:PGXN&diff=11025Talk:PGXN2010-05-27T04:08:00Z<p>Theory: Talk:PGAN moved to Talk:PgDEX: New name for the project.</p>
<hr />
<div>== Possible FAQ Addition ==<br />
<br />
How to pronounce PGAN? (P-G-An, P-Gan?)</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGAN&diff=11024PGAN2010-05-27T04:07:59Z<p>Theory: PGAN moved to PgDEX: New name for the project.</p>
<hr />
<div>#REDIRECT [[PgDEX]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=11023PGXN2010-05-27T04:07:59Z<p>Theory: PGAN moved to PgDEX: New name for the project.</p>
<hr />
<div>This document outlines the specification for the creation of PGAN, the PostgreSQL Add-on Network. The purpose of PGAN is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# PAUS: The PostgreSQL Authors Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PGAN.<br />
<br />
=PAUS=<br />
<br />
The models for PAUS include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (paus.pgan.org), if possible use existing postgresql.org logins. From there, users can upload release tarballs to the site and add or delete release managers.<br />
<br />
Once a tarball is uploaded, it is considered released and its name registered to the uploading user. PAUS will add its metadata to its database and add the tarball and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PGAN. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via PAUS.<br />
<br />
PAUS will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to PAUS as Gzip- or Bzip2-compressed tarballs. A distribution tarball is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PGAN Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PGAN. The names "PostgreSQL", "Postgres", and "pgsql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>: This is the standard PGXS build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>: The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>: May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>: Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>: Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>: Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PGAN Directory=<br />
<br />
The entire directory of PGAN will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PGAN for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PGAN database and listed on the PGAN Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PGAN will contain information about all the distributions on PGAN, including relevant metadata. It will also include information about registered PGAN users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow users of the site to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from PAUS hourly, and will include a feed of recent releases uploaded to the PGAN. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PGAN to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PGAN Client=<br />
<br />
The PGAN client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN client] and the [http://search.cpan.org/perldoc?jsan JSAN client]. Essentially, it will provide an interface to easily download, build, test, and install PGAN distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN and JSAN clients.<br />
<br />
For the initial implementation, the PGAN client will assume that extensions can be built using PGXS with:<br />
<br />
<code>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</code><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PGAN shell will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PGAN client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. To the extent that PGXS-powered `make` works on a given platform, the client will support it.<br />
<br />
The PGAN client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PGAN index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PGAN is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PGAN infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PGAN=<br />
<br />
Once the initial implementation of PGAN is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution tarball ready for release on PGAN.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the tarball, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PGAN RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PGAN extensions.<br />
* PGAN Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PGAN?''' Open-source PostgreSQL extension release tarballs. The current contrib extensions serve as the model for the contents of such tarballs. Following the [http://www.cpan.org/misc/ZCAN.html CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PGAN?''' Non-tarball files and non-open-source distributions and distributions with no license.<br />
* '''Who can release on PGAN?''' Any registered user.<br />
* '''Who can register for PGAN?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PGAN needs to [http://en.wikipedia.org/wiki/KISS_principle KISS].Longer answer: No. Again following the [http://www.cpan.org/misc/ZCAN.html CPAN example], PGAN "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of [PGAN] is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of the CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL.PGAN will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting.The only thing in common with pgFoundry is uploading release tarballs. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PGAN installer will be updated to take advantage of new features. Such improvements are expected to make PGAN more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PGAN.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PGAN will take advantage of them, but none are required in order to bootstrap PGAN.<br />
* '''How will PGAN make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PGAN with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PGAN client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves such that a compiler is no longer required, the PGAN client will be modified as appropriate to take advantage of it. This applies not specifically to Windows, but to the ability of the core intaller (or any future community-supported installer) to work on ''any'' platform.<br />
* '''What kind of security will it have?''' Each release tarball will have an accompanying SHA1 hash that the PGAN client will verify before installing an extension.<br />
<br />
=References=<br />
* [http://www.cpan.org/misc/ZCAN.html The Zen of Comprehensive Archive Networks]<br />
* [http://use.perl.org/comments.pl?sid=9630&cid=14713 Easier than you think] (comment on ZCAN)<br />
* [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod The CPAN Meta spec]<br />
* [http://wiki.postgresql.org/wiki/ExtensionPackaging PostgreSQL Extensions Proposal]<br />
* [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]<br />
* [http://trac.parrot.org/parrot/wiki/ModuleEcosystem The Parrot Module Ecosystem]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=9548PGXN2010-01-15T17:25:09Z<p>Theory: Updated ZCAN links.</p>
<hr />
<div>This document outlines the specification for the creation of PGAN, the PostgreSQL Add-on Network. The purpose of PGAN is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# PAUS: The PostgreSQL Authors Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PGAN.<br />
<br />
=PAUS=<br />
<br />
The models for PAUS include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (paus.pgan.org), if possible use existing postgresql.org logins. From there, users can upload release tarballs to the site and add or delete release managers.<br />
<br />
Once a tarball is uploaded, it is considered released and its name registered to the uploading user. PAUS will add its metadata to its database and add the tarball and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PGAN. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via PAUS.<br />
<br />
PAUS will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to PAUS as Gzip- or Bzip2-compressed tarballs. A distribution tarball is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PGAN Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PGAN. The names "PostgreSQL", "Postgres", and "pgsql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>: This is the standard PGXS build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>: The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>: May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>: Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>: Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>: Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PGAN Directory=<br />
<br />
The entire directory of PGAN will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PGAN for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PGAN database and listed on the PGAN Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PGAN will contain information about all the distributions on PGAN, including relevant metadata. It will also include information about registered PGAN users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow users of the site to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from PAUS hourly, and will include a feed of recent releases uploaded to the PGAN. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PGAN to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PGAN Client=<br />
<br />
The PGAN client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN client] and the [http://search.cpan.org/perldoc?jsan JSAN client]. Essentially, it will provide an interface to easily download, build, test, and install PGAN distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN and JSAN clients.<br />
<br />
For the initial implementation, the PGAN client will assume that extensions can be built using PGXS with:<br />
<br />
<code>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</code><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PGAN shell will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PGAN client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. To the extent that PGXS-powered `make` works on a given platform, the client will support it.<br />
<br />
The PGAN client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PGAN index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PGAN is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PGAN infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PGAN=<br />
<br />
Once the initial implementation of PGAN is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution tarball ready for release on PGAN.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the tarball, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PGAN RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PGAN extensions.<br />
* PGAN Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PGAN?''' Open-source PostgreSQL extension release tarballs. The current contrib extensions serve as the model for the contents of such tarballs. Following the [http://www.cpan.org/misc/ZCAN.html CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PGAN?''' Non-tarball files and non-open-source distributions and distributions with no license.<br />
* '''Who can release on PGAN?''' Any registered user.<br />
* '''Who can register for PGAN?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PGAN needs to [http://en.wikipedia.org/wiki/KISS_principle KISS].Longer answer: No. Again following the [http://www.cpan.org/misc/ZCAN.html CPAN example], PGAN "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of [PGAN] is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of the CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL.PGAN will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting.The only thing in common with pgFoundry is uploading release tarballs. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PGAN installer will be updated to take advantage of new features. Such improvements are expected to make PGAN more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PGAN.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PGAN will take advantage of them, but none are required in order to bootstrap PGAN.<br />
* '''How will PGAN make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PGAN with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PGAN client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves such that a compiler is no longer required, the PGAN client will be modified as appropriate to take advantage of it. This applies not specifically to Windows, but to the ability of the core intaller (or any future community-supported installer) to work on ''any'' platform.<br />
* '''What kind of security will it have?''' Each release tarball will have an accompanying SHA1 hash that the PGAN client will verify before installing an extension.<br />
<br />
=References=<br />
* [http://www.cpan.org/misc/ZCAN.html The Zen of Comprehensive Archive Networks]<br />
* [http://use.perl.org/comments.pl?sid=9630&cid=14713 Easier than you think] (comment on ZCAN)<br />
* [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod The CPAN Meta spec]<br />
* [http://wiki.postgresql.org/wiki/ExtensionPackaging PostgreSQL Extensions Proposal]<br />
* [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]<br />
* [http://trac.parrot.org/parrot/wiki/ModuleEcosystem The Parrot Module Ecosystem]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=9507PGXN2010-01-10T00:23:25Z<p>Theory: Added references.</p>
<hr />
<div>This document outlines the specification for the creation of PGAN, the PostgreSQL Add-on Network. The purpose of PGAN is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# PAUS: The PostgreSQL Authors Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PGAN.<br />
<br />
=PAUS=<br />
<br />
The models for PAUS include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (paus.pgan.org), if possible use existing postgresql.org logins. From there, users can upload release tarballs to the site and add or delete release managers.<br />
<br />
Once a tarball is uploaded, it is considered released and its name registered to the uploading user. PAUS will add its metadata to its database and add the tarball and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PGAN. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via PAUS.<br />
<br />
PAUS will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to PAUS as Gzip- or Bzip2-compressed tarballs. A distribution tarball is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PGAN Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PGAN. The names "PostgreSQL", "Postgres", and "pgsql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>: This is the standard PGXS build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>: The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>: May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>: Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>: Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>: Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PGAN Directory=<br />
<br />
The entire directory of PGAN will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PGAN for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PGAN database and listed on the PGAN Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PGAN will contain information about all the distributions on PGAN, including relevant metadata. It will also include information about registered PGAN users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow users of the site to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from PAUS hourly, and will include a feed of recent releases uploaded to the PGAN. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PGAN to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PGAN Client=<br />
<br />
The PGAN client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN client] and the [http://search.cpan.org/perldoc?jsan JSAN client]. Essentially, it will provide an interface to easily download, build, test, and install PGAN distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN and JSAN clients.<br />
<br />
For the initial implementation, the PGAN client will assume that extensions can be built using PGXS with:<br />
<br />
<code>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</code><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PGAN shell will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PGAN client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. To the extent that PGXS-powered `make` works on a given platform, the client will support it.<br />
<br />
The PGAN client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PGAN index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PGAN is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PGAN infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PGAN=<br />
<br />
Once the initial implementation of PGAN is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution tarball ready for release on PGAN.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the tarball, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PGAN RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PGAN extensions.<br />
* PGAN Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PGAN?''' Open-source PostgreSQL extension release tarballs. The current contrib extensions serve as the model for the contents of such tarballs. Following the [http://use.perl.org/article.pl?sid=02/11/12/1616209 CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PGAN?''' Non-tarball files and non-open-source distributions and distributions with no license.<br />
* '''Who can release on PGAN?''' Any registered user.<br />
* '''Who can register for PGAN?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PGAN needs to [http://en.wikipedia.org/wiki/KISS_principle KISS].Longer answer: No. Again following the [http://use.perl.org/article.pl?sid=02/11/12/1616209 CPAN example], PGAN "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of [PGAN] is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of the CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL.PGAN will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting.The only thing in common with pgFoundry is uploading release tarballs. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PGAN installer will be updated to take advantage of new features. Such improvements are expected to make PGAN more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PGAN.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PGAN will take advantage of them, but none are required in order to bootstrap PGAN.<br />
* '''How will PGAN make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PGAN with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PGAN client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves such that a compiler is no longer required, the PGAN client will be modified as appropriate to take advantage of it. This applies not specifically to Windows, but to the ability of the core intaller (or any future community-supported installer) to work on ''any'' platform.<br />
* '''What kind of security will it have?''' Each release tarball will have an accompanying SHA1 hash that the PGAN client will verify before installing an extension.<br />
<br />
=References=<br />
* [http://use.perl.org/article.pl?sid=02/11/12/1616209 The Zen of Comprehensive Archive Networks]<br />
* [http://use.perl.org/comments.pl?sid=9630&cid=14713 Easier than you think] (comment on ZCAN)<br />
* [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod The CPAN Meta spec]<br />
* [http://wiki.postgresql.org/wiki/ExtensionPackaging PostgreSQL Extensions Proposal]<br />
* [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]<br />
* [http://trac.parrot.org/parrot/wiki/ModuleEcosystem The Parrot Module Ecosystem]</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=9501PGXN2010-01-08T17:13:53Z<p>Theory: Reword Windows stuff.</p>
<hr />
<div>This document outlines the specification for the creation of PGAN, the PostgreSQL Add-on Network. The purpose of PGAN is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# PAUS: The PostgreSQL Authors Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PGAN.<br />
<br />
=PAUS=<br />
<br />
The models for PAUS include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (paus.pgan.org), if possible use existing postgresql.org logins. From there, users can upload release tarballs to the site and add or delete release managers.<br />
<br />
Once a tarball is uploaded, it is considered released and its name registered to the uploading user. PAUS will add its metadata to its database and add the tarball and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PGAN. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via PAUS.<br />
<br />
PAUS will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to PAUS as Gzip- or Bzip2-compressed tarballs. A distribution tarball is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PGAN Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PGAN. The names "PostgreSQL", "Postgres", and "pgsql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>: This is the standard PGXS build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>: The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>: May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>: Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>: Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>: Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PGAN Directory=<br />
<br />
The entire directory of PGAN will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PGAN for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PGAN database and listed on the PGAN Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PGAN will contain information about all the distributions on PGAN, including relevant metadata. It will also include information about registered PGAN users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow users of the site to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from PAUS hourly, and will include a feed of recent releases uploaded to the PGAN. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PGAN to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PGAN Client=<br />
<br />
The PGAN client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN client] and the [http://search.cpan.org/perldoc?jsan JSAN client]. Essentially, it will provide an interface to easily download, build, test, and install PGAN distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN and JSAN clients.<br />
<br />
For the initial implementation, the PGAN client will assume that extensions can be built using PGXS with:<br />
<br />
<code>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</code><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PGAN shell will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PGAN client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. To the extent that PGXS-powered `make` works on a given platform, the client will support it.<br />
<br />
The PGAN client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PGAN index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PGAN is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PGAN infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PGAN=<br />
<br />
Once the initial implementation of PGAN is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution tarball ready for release on PGAN.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the tarball, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PGAN RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PGAN extensions.<br />
* PGAN Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PGAN?''' Open-source PostgreSQL extension release tarballs. The current contrib extensions serve as the model for the contents of such tarballs. Following the [http://use.perl.org/article.pl?sid=02/11/12/1616209 CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PGAN?''' Non-tarball files and non-open-source distributions and distributions with no license.<br />
* '''Who can release on PGAN?''' Any registered user.<br />
* '''Who can register for PGAN?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PGAN needs to [http://en.wikipedia.org/wiki/KISS_principle KISS].Longer answer: No. Again following the [http://use.perl.org/article.pl?sid=02/11/12/1616209 CPAN example], PGAN "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of [PGAN] is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of the CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL.PGAN will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting.The only thing in common with pgFoundry is uploading release tarballs. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PGAN installer will be updated to take advantage of new features. Such improvements are expected to make PGAN more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PGAN.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PGAN will take advantage of them, but none are required in order to bootstrap PGAN.<br />
* '''How will PGAN make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PGAN with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PGAN client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves such that a compiler is no longer required, the PGAN client will be modified as appropriate to take advantage of it. This applies not specifically to Windows, but to the ability of the core intaller (or any future community-supported installer) to work on ''any'' platform.<br />
* '''What kind of security will it have?''' Each release tarball will have an accompanying SHA1 hash that the PGAN client will verify before installing an extension.</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=9485PGXN2010-01-07T22:40:10Z<p>Theory: HTML::WikiConverter did a shitty job. Fixed "Other Contents" list items.</p>
<hr />
<div>This document outlines the specification for the creation of PGAN, the PostgreSQL Add-on Network. The purpose of PGAN is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# PAUS: The PostgreSQL Authors Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PGAN.<br />
<br />
=PAUS=<br />
<br />
The models for PAUS include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (paus.pgan.org), if possible use existing postgresql.org logins. From there, users can upload release tarballs to the site and add or delete release managers.<br />
<br />
Once a tarball is uploaded, it is considered released and its name registered to the uploading user. PAUS will add its metadata to its database and add the tarball and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PGAN. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via PAUS.<br />
<br />
PAUS will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to PAUS as Gzip- or Bzip2-compressed tarballs. A distribution tarball is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PGAN Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PGAN. The names "PostgreSQL", "Postgres", and "pgsql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>: This is the standard PGXS build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>: The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>: May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>: Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>: Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>: Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PGAN Directory=<br />
<br />
The entire directory of PGAN will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PGAN for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PGAN database and listed on the PGAN Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PGAN will contain information about all the distributions on PGAN, including relevant metadata. It will also include information about registered PGAN users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow users of the site to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from PAUS hourly, and will include a feed of recent releases uploaded to the PGAN. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PGAN to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PGAN Client=<br />
<br />
The PGAN client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN client] and the [http://search.cpan.org/perldoc?jsan JSAN client]. Essentially, it will provide an interface to easily download, build, test, and install PGAN distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN and JSAN clients.<br />
<br />
For the initial implementation, the PGAN client will assume that extensions can be built using PGXS with:<br />
<br />
<code>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</code><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PGAN shell will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PGAN client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. In the short run, that likely means that Windows will not be supported unless there is a relevant <code>make</code> utility.<br />
<br />
The PGAN client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PGAN index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PGAN is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PGAN infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PGAN=<br />
<br />
Once the initial implementation of PGAN is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution tarball ready for release on PGAN.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the tarball, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PGAN RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PGAN extensions.<br />
* PGAN Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PGAN?''' Open-source PostgreSQL extension release tarballs. The current contrib extensions serve as the model for the contents of such tarballs. Following the [http://use.perl.org/article.pl?sid=02/11/12/1616209 CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PGAN?''' Non-tarball files and non-open-source distributions and distributions with no license.<br />
* '''Who can release on PGAN?''' Any registered user.<br />
* '''Who can register for PGAN?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PGAN needs to [http://en.wikipedia.org/wiki/KISS_principle KISS].Longer answer: No. Again following the [http://use.perl.org/article.pl?sid=02/11/12/1616209 CPAN example], PGAN "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of [PGAN] is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of the CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL.PGAN will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting.The only thing in common with pgFoundry is uploading release tarballs. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PGAN installer will be updated to take advantage of new features. Such improvements are expected to make PGAN more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PGAN.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PGAN will take advantage of them, but none are required in order to bootstrap PGAN.<br />
* '''How will PGAN make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PGAN with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PGAN client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves, the PGAN client will be modified as appropriate to take advantage of it.<br />
* '''What kind of security will it have?''' Each release tarball will have an accompanying SHA1 hash that the PGAN client will verify before installing an extension.</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=9484PGXN2010-01-07T22:30:22Z<p>Theory: Added "WTF is an extension?" to FAQ.</p>
<hr />
<div>This document outlines the specification for the creation of PGAN, the PostgreSQL Add-on Network. The purpose of PGAN is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# PAUS: The PostgreSQL Authors Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PGAN.<br />
<br />
=PAUS=<br />
<br />
The models for PAUS include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (paus.pgan.org), if possible use existing postgresql.org logins. From there, users can upload release tarballs to the site and add or delete release managers.<br />
<br />
Once a tarball is uploaded, it is considered released and its name registered to the uploading user. PAUS will add its metadata to its database and add the tarball and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PGAN. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via PAUS.<br />
<br />
PAUS will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to PAUS as Gzip- or Bzip2-compressed tarballs. A distribution tarball is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PGAN Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PGAN. The names "PostgreSQL", "Postgres", and "pgsql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>This is the standard PGXS build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PGAN Directory=<br />
<br />
The entire directory of PGAN will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PGAN for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PGAN database and listed on the PGAN Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PGAN will contain information about all the distributions on PGAN, including relevant metadata. It will also include information about registered PGAN users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow users of the site to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from PAUS hourly, and will include a feed of recent releases uploaded to the PGAN. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PGAN to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PGAN Client=<br />
<br />
The PGAN client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN client] and the [http://search.cpan.org/perldoc?jsan JSAN client]. Essentially, it will provide an interface to easily download, build, test, and install PGAN distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN and JSAN clients.<br />
<br />
For the initial implementation, the PGAN client will assume that extensions can be built using PGXS with:<br />
<br />
<code>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</code><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PGAN shell will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PGAN client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. In the short run, that likely means that Windows will not be supported unless there is a relevant <code>make</code> utility.<br />
<br />
The PGAN client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PGAN index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PGAN is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PGAN infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PGAN=<br />
<br />
Once the initial implementation of PGAN is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution tarball ready for release on PGAN.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the tarball, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PGAN RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PGAN extensions.<br />
* PGAN Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* '''What's allowed to be released on PGAN?''' Open-source PostgreSQL extension release tarballs. The current contrib extensions serve as the model for the contents of such tarballs. Following the [http://use.perl.org/article.pl?sid=02/11/12/1616209 CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* '''WTF is an "extension"?''' An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. See [http://www.postgresql.org/docs/8.4/static/extend.html Extending SQL]) for details. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).<br />
* '''What's ''not'' allowed to be released on PGAN?''' Non-tarball files and non-open-source distributions and distributions with no license.<br />
* '''Who can release on PGAN?''' Any registered user.<br />
* '''Who can register for PGAN?''' Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* '''Will there be an approval process?''' Short answer: No, because PGAN needs to [http://en.wikipedia.org/wiki/KISS_principle KISS].Longer answer: No. Again following the [http://use.perl.org/article.pl?sid=02/11/12/1616209 CPAN example], PGAN "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of [PGAN] is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of the CPAN.<br />
* '''How is this different from pgFoundry?''' pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL.PGAN will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting.The only thing in common with pgFoundry is uploading release tarballs. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* '''Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?''' No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PGAN installer will be updated to take advantage of new features. Such improvements are expected to make PGAN more successful, but are not required to get it started now.<br />
* '''But don't you need the naming scheme to be worked out first?''' That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PGAN.<br />
* '''Will it require changes to PGXS?''' No. As changes are made to PGXS, PGAN will take advantage of them, but none are required in order to bootstrap PGAN.<br />
* '''How will PGAN make it easy to distinguish the garbage from the viable extensions?''' The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PGAN with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* '''What about Windows?''' The PGAN client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves, the PGAN client will be modified as appropriate to take advantage of it.<br />
* '''What kind of security will it have?''' Each release tarball will have an accompanying SHA1 hash that the PGAN client will verify before installing an extension.</div>Theoryhttps://wiki.postgresql.org/index.php?title=PGXN&diff=9473PGXN2010-01-07T19:33:37Z<p>Theory: First draft.</p>
<hr />
<div>This document outlines the specification for the creation of PGAN, the PostgreSQL Add-on Network. The purpose of PGAN is to provide a central repository and distribution system for open-source PostgreSQL extension libraries. In its first iteration it will consist of four basic parts:<br />
<br />
# PAUS: The PostgreSQL Authors Upload Server. Users will be able to create logins and upload extension distributions.<br />
# An <code>rsync</code>-able directory of extension distributions and metadata.<br />
# A site for searching through extension releases and perusing extension documentation.<br />
# A command-line client for downloading, testing, and installing extensions.<br />
<br />
This document outlines the details for the structure of this first iteration of PGAN.<br />
<br />
=PAUS=<br />
<br />
The models for PAUS include [https://pause.perl.org PAUSE] and [https://master.openjsan.org/jause/ JAUSE]. The interface will be very simple: A site to login to (paus.pgan.org), if possible use existing postgresql.org logins. From there, users can upload release tarballs to the site and add or delete release managers.<br />
<br />
Once a tarball is uploaded, it is considered released and its name registered to the uploading user. PAUS will add its metadata to its database and add the tarball and updated metadata to the <code>rsync</code>-able directory.<br />
<br />
Extensions are unique by name across PGAN. If user "theory" uploads a extension named "pgTAP", no other user will be able to upload an extension with that name unless "theory" adds them as release managers via PAUS.<br />
<br />
PAUS will have a Web UI for easy extension release, but will also provide a complete Web API so that release management can be scripted.<br />
<br />
=Distribution Layout=<br />
<br />
Distributions may be uploaded to PAUS as Gzip- or Bzip2-compressed tarballs. A distribution tarball is required to have a file named <code>META.json</code> in its root directory. All other files and directories are optional, but may be required for added functionality on the search site or in the command-line client.<br />
<br />
==PGAN Meta==<br />
<br />
<code>META.json</code> is a [http://www.json.org JSON]-formatted document containing metadata about the distribution, following the [http://github.com/dagolden/cpan-meta-spec/blob/master/META-spec.pod CPAN Meta spec], which has the advantage of being developed over the course of the last 10 years. This meta file describes the extension and its dependencies. Although most or all of the structure supported by the CPAN meta spec will be supported, at a minimum, the required keys will be:<br />
<br />
* <code>name</code>: The name of the extension. This must be unique across all extensions on PGAN. The names "PostgreSQL", "Postgres", and "pgsql" will be reserved.<br />
* <code>version</code>: The release version of the extension. This must be unique across all versions of the extension and must be numeric.<br />
* <code>license</code>: The license or licenses under which the extension is distributed.<br />
<br />
Other keys may be required for added functionality in the command-line client or the search site.<br />
<br />
==Other Contents==<br />
<br />
All other files are optional or may be put wherever makes sense for the build. There will, however, be a number of additional organizational expectations from the search site and the command-line client. Note that these are recommendations, but will make it easier to install an extension or to gain higher visibility on the search site.<br />
<br />
* <code>Makefile</code>This is the standard PGXS build system for PostgreSQL extensions. See the contrib modules for examples.<br />
* <code>t/</code> or <code>test/</code> or <code>tests/</code> or <code>sql/</code>The test suite for the extension. The command-line client will always look for and run tests. If the files are in <code>sql/</code> and there is also an <code>expected/</code> directory, the tests are assumed to be <code>pg_regress</code> tests. Otherwise, they will be assumed to be [http://pgtap.projects.postgresql.org/ pgTAP] tests.<br />
* <code>README</code> or <code>README.$extension_name</code>May contain anything you like, but would recommend that it contain a high-level introduction to the extension, in which the author tries to convince the reader how awesome the extension is, as succinctly as possible. May also include installation instructions, or they may be placed in a separate <code>INSTALL</code> file (which may be more useful when there are third-party dependencies to satisfy).<br />
* <code>LICENSE</code>Under what terms is the extension and all the other stuff in the distribution distributed?<br />
* <code>Changes</code> or <code>ChangeLog</code>Keep users abreast of the latest changes.<br />
* <code>doc</code> or <code>docs</code> or <code>documentation</code>Documentation for the extension. May include any number of files. The search site will convert these to HTML for display on the site. The formats it will support must be indicated by file name extensions. Initially, we'll aim to support the formats and file-name suffixes supported by [http://github.com/guides/readme-formatting GitHub]. The contents of the <code>&lt;title&gt;</code> tag in the resulting HTML files will be used to create links to the documentation files.<br />
<br />
=PGAN Directory=<br />
<br />
The entire directory of PGAN will be available for mirroring via <code>rsync</code>. This will allow anyone to create mirrors of PGAN for purposes of broader distribution or for private use. Mirror hosts can register as official mirrors, in which case their mirrors will be included in PGAN database and listed on the PGAN Web site.<br />
<br />
=Search Site=<br />
<br />
The main site for PGAN will contain information about all the distributions on PGAN, including relevant metadata. It will also include information about registered PGAN users, including a list of extensions released by each user. Furthermore, any documentation included in distributions will be formatted as individual HTML files on the site. And most importantly, all of the content of the site will be indexed and searchable. This functionality will be modeled on [http://search.cpan.org/ search.cpan.org] and [http://openjsan.org/ OpenJSAN].<br />
<br />
The first goal of the site is to allow users of the site to search for extensions that might meet their particular needs, and be able to read the documentation before downloading. The search engine will highlight the names, abstracts, and keywords of the modules, with secondary importance given to the entire contents of the documentation of each module.<br />
<br />
The site will be updated from PAUS hourly, and will include a feed of recent releases uploaded to the PGAN. This will make it easy for people to follow new developments in the PostgreSQL extension community in their news readers, as well as to integrate release information into other sites (such as a box on the main PostgreSQL site).<br />
<br />
The second goal of the site is to highlight PostgreSQL extensions as a community resource, making it easy to find extensions via Google searches and the like. As bloggers and publications use direct links to the documentation for particular extensions, search rankings will only increase, exposing extensions included in the PGAN to wider visibility. This model has worked extremely well for the Perl community via [http://search.cpan.org/ search.cpan.org], and can work as well to highlight the extensibility and availability of extensions for PostgreSQL.<br />
<br />
=PGAN Client=<br />
<br />
The PGAN client will be a command-line client modeled on the [http://search.cpan.org/perldoc?cpan CPAN client] and the [http://search.cpan.org/perldoc?jsan JSAN client]. Essentially, it will provide an interface to easily download, build, test, and install PGAN distributions. It will be written in Perl so as to maximize the benefits provided by the existing CPAN and JSAN clients.<br />
<br />
For the initial implementation, the PGAN client will assume that extensions can be built using PGXS with:<br />
<br />
<code>make USE_PGXS=1<br />
make USE_PGXS=1 install<br />
make USE_PGXS=1 installcheck<br />
</code><br />
<br />
If there is no <code>expected</code> directory in a distribution, rather than running <code>make installcheck</code>, the PGAN shell will assume that any tests are pgTAP tests an run them as such instead. This will lower the barrier to writing tests, as test writers won't have to maintain expected output files as <code>pg_regress</code> requires.<br />
<br />
The PGAN client will make no other assumptions about how to build and install extensions, leaving such to the PostgreSQL core. In the short run, that likely means that Windows will not be supported unless there is a relevant <code>make</code> utility.<br />
<br />
The PGAN client will be configurable via a configuration file as well as at runtime. Configurations will include (among other settings):<br />
<br />
* What mirrors to use<br />
* What command to use to build (e.g., <code>gmake</code>)<br />
* What command to use to install (e.g., <code>sudo make</code>)<br />
* Where to cache data (PGAN index, downloads, builds, etc.)<br />
* Location of <code>pg_config</code><br />
<br />
Upon the first run, it will do its best to self-configure, so that users can immediately start downloading and building extensions with a minimum of hassle.<br />
<br />
=Implications for PostgreSQL=<br />
<br />
The design of the PGAN is such as to allow extensions to be created and released using the existing infrastructure provided by PostgreSQL itself. It has no opinions about [http://wiki.postgresql.org/wiki/ExtensionPackaging how extensions should be built or improved] in PostgreSQL, being focused more on distribution, documentation, community exposure, and ease of installation. Whatever decisions are made in this regard, the PGAN infrastructure will be updated as necessary to make the most of it.<br />
<br />
=Building on PGAN=<br />
<br />
Once the initial implementation of PGAN is complete and deployed, we can start building other tools to enhance its value to the community and to users. These include tools in the PostgreSQL core to make it easier to create, test, and install extension distributions, as well as tools to assist in the evaluation of extensions.<br />
<br />
Think of this section as ideas for phase 2 projects. Some examples:<br />
<br />
* New PGXS targetsTo make extension creation and release management simpler, some new features for PGXS can be contributed to the PostgreSQL core. Such features might include new make targets to support extensions:<br />
** <code>make distmeta</code>: Generate a <code>META.json</code> file from the contents of variables in <code>Makefile</code>.<br />
** <code>make test</code>: Build a new database cluster and start PostgreSQL on an unreserved port -- including any DSOs created by <code>make</code> -- and then run the extension's test suite.<br />
** <code>make dist</code>: Create a distribution tarball ready for release on PGAN.<br />
** <code>make distcheck</code>: Like <code>make dist</code>, but instead of creating the tarball, it creates a distribution directory and then runs <code>make test</code>.One functional change might make it simpler to specify a schema into which to install an extension, like so:psql --set INSTALLSCHEMA=extensions extesion.sql<br />
* PGAN RatingsLike [http://cpanratings.perl.org/ CPAN Ratings], users would be able to review and rate individual PGAN extensions.<br />
* PGAN Testers. Like [http://www.cpantesters.org/ CPAN Testers], volunteers can set up sandboxed test environments to regularly run tests and report results to a central database. This will allow ongoing testing to ensure that extensions work on various platforms and with various versions of PostgreSQL. Such results will help maintainers to keep their extensions working in supported environments and users to evaluate how well maintained extensions are.<br />
<br />
=FAQ=<br />
<br />
* What's allowed to be released on PGAN?Open-source PostgreSQL extension release tarballs. The current contrib extensions serve as the model for the contents of such tarballs. Following the [http://use.perl.org/article.pl?sid=02/11/12/1616209 CPAN example], "no commercial software of any kind, not even share/guilt/donateware, will be allowed…any other policy would be open to nitpicking, or maybe even legal challenges."<br />
* What's ''not'' allowed to be released on PGAN?Non-tarball files and non-open-source distributions and distributions with no license.<br />
* Who can release on PGAN?Any registered user.<br />
* Who can register for PGAN?Anyone who applies. Such registrations will be approved by volunteers, though if the existing community registrations can be used, that would be preferred.<br />
* Will there be an approval process?Short answer: No, because PGAN needs to [http://en.wikipedia.org/wiki/KISS_principle KISS].Longer answer: No. Again following the [http://use.perl.org/article.pl?sid=02/11/12/1616209 CPAN example], PGAN "will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora." This is because "[http://use.perl.org/comments.pl?sid=9630&cid=14713 the first goal] of [PGAN] is to make it easy to submit code and redistribute it. Ease of use and quality control are not the central problems [it] tries to solve." Frankly, moderation of releases is a significant reason that other communities have failed to duplicate the success of the CPAN.<br />
* How is this different from pgFoundry?pgFoundry is for project hosting and includes SCM, issue tracking, mailing lists, Web hosting, and mirrored download support for any project related to PostgreSQL.PGAN will be for extensions distribution and mirroring, easy downloading and installation, documentation and metadata, and searching and reporting.The only thing in common with pgFoundry is uploading release tarballs. They otherwise serve very different purposes (project management vs. distribution and exposure).<br />
* Don't we need to wait for [http://wiki.postgresql.org/wiki/ExtensionPackaging extensions in core]?No. The current support for building extensions as exhibited by the contrib extensions works for most platforms. As core extension support improves, the PGAN installer will be updated to take advantage of new features. Such improvements are expected to make PGAN more successful, but are not required to get it started now.<br />
* But don't you need the naming scheme to be worked out first?That might be ideal, but for now it will be adequate to simply require a unique name for a given extension. Once core supports formal extensions, its naming scheme will be adopted by PGAN.<br />
* Will it require changes to PGXS?No. As changes are made to PGXS, PGAN will take advantage of them, but none are required in order to bootstrap PGAN.<br />
* How will PGAN make it easy to distinguish the garbage from the viable extensions?The first step will be the search site, which will allow users to find extensions relevant to them and read their documentation. This will "often [be] enough to distinguish the good stuff from the crap," as Robert Haas [http://archives.postgresql.org/pgsql-www/2010-01/msg00057.php says]. As more extensions are released on PGAN with competing features and functionality, the addition of ratings features and dedicated testing will also make it easier to evaluate competing options.<br />
* What about Windows?The PGAN client will always follow the lead of the PostgreSQL core on installing extensions. If support for installing extensions on Windows improves, the PGAN client will be modified as appropriate to take advantage of it.<br />
* What kind of security will it have?<br />
<br />
Each release tarball will have an accompanying SHA1 hash that the PGAN client will verify before installing an extension.</div>Theoryhttps://wiki.postgresql.org/index.php?title=HowToBetaTest&diff=8118HowToBetaTest2009-09-18T18:12:34Z<p>Theory: Added a couple of Perl apps with test suites.</p>
<hr />
<div>= HOWTO Alpha and Beta Test =<br />
<br />
If you are not a code contributor (or even if you are) testing PostgreSQL Alphas and Betas is one of the best things you can do for our project. By participating in organized testing, you help get the release out faster, with more features and less bugs.<br />
<br />
== Prerequisites to Testing ==<br />
<br />
A. '''Join the [http://archives.postgresql.org/pgsql-testers/ pgsql-testers Mailing List].''' This list is where you will submit test reports, as well as asking questions and discussing testing.<br />
<br />
B. '''Have a Test Machine''': somewhere you can run tests on a PostgreSQL database and/or application, even if they may result in using all of your computer's system resources, or crashing. If your company uses PostgreSQL and you have a testbed for development changes, this is ideal.<br />
<br />
C. '''Have a Test''': an application test, interface test, performance test, and/or database feature test you can run. See below for explanations of this or suggestions. <br />
<br />
D. '''Have Some Time''': for testing when new Alphas or Betas come out. It doesn't have to be a lot of time, but do expect to spend a couple hours testing, and following up on questions from PostgreSQL hackers, with each release.<br />
<br />
== Types of Tests You Can Run ==<br />
<br />
=== Install Test ===<br />
<br />
This is the simplest one, and precedes all of the others. Install the new version of PostgreSQL. Configure it with your favorite options and contrib modules and external tools. Does it all work?<br />
<br />
=== Custom Application Tests ===<br />
<br />
If you're already using PostgreSQL in production on your custom application, try porting your application to the new release and run your own application tests and performance tests. Try upgrading a copy of a populated database and seeing if there are any upgrade errors. Tell us what you find.<br />
<br />
This is more valuable, of course, if your application has a full testing framework which allows you to unit test your application functions and its overall performance. But even doing some ad-hoc user testing of the upgrade is helpful.<br />
<br />
=== General Application Tests ===<br />
<br />
Some popular open source and proprietary applications come with their own test suites, unit tests, and/or performance tests. At some point, we will have a list of these; if you know one, please add it. For each of these, you can test the following things:<br />
<br />
* Upgrading a populated database<br />
* Create a new database using the software's installer<br />
* Run unit tests and look for errors<br />
* Run performance tests and look for performance regression<br />
<br />
Open Source applications with test frameworks:<br />
<br />
* Rails Apps:<br />
** [http://www.fatfreecrm.com/ Fat Free CRM]<br />
** [http://www.redmine.org/ Redmine]<br />
** [http://radiantcms.org/ RadiantCMD]<br />
** [http://github.com/insoshi/insoshi Inoshi]<br />
* ORMs<br />
** SQL Alchemy<br />
** DataObjects<br />
** DataMapper<br />
** ActiveRecord<br />
* PHP Apps:<br />
** phpPgAdmins<br />
* Perl Apps:<br />
** [http://www.briclolagecms.org/ Bricolage CMS]<br />
** [http://bestpractical.com/rt/ Request Tracker]<br />
<br />
=== Interface Tests ===<br />
<br />
Nobody can use PostgreSQL without a driver, and we want to make sure that all of our drivers work as well as possible with each new version of PostgreSQL. We particularly want to make sure that new features don't break these drivers. Fortunately, many drivers have regression tests.<br />
<br />
So, download the latest version of your favorite driver (and maybe some others you don't like as much, but are still current/popular) point them at the new release of PostgreSQL, and run the regression tests. Then, build a simple database with some of the new release's features, and try to query them; do new syntax or new data types break the driver?<br />
<br />
=== Performance Tests ===<br />
<br />
Another critical thing to check for is performance regressions and improvements. The difficulty about testing for this is that you really need to be sure to conduct your tests in a manner which produces repeatable results, or the performance metrics aren't worthwhile. This means that you should run them on a system which has nothing else running other than the test, you should run the test several times and see if results are consistent, etc. You also need to run the test or benchmark both against the previous version (e.g. 8.4.1) and the current alpha or beta.<br />
<br />
Performance tests you can run include:<br />
* An application performance benchmark, if your custom or public application has one.<br />
* pgbench. Instructions on getting useful results from pgbench up later.<br />
* Real benchmarks like DBT2, Spec's EAStress, etc. These require a large investment in time and server hardware to run.<br />
* Specific task peformance; try running an operation which you know strains PG's resources (like a 40-table JOIN or an ELT operation) or one which is supposed to be improved in the new release.<br />
<br />
If you start running performance tests, it's very important that you stick with it for the whole alpha/beta cycle so that we can see if we're improving and/or fixing any problems.<br />
<br />
=== Feature Tests ===<br />
<br />
Every alpha or beta release has new features. While our contributors do a good job of testing each feature in isolation, the combinatorics of testing each new feature with every other new feature, as well as with old features, is impossible for the hackers. Also, we're so close to the code that we can miss leaving major things out of the docs. This is where you come in. Things to test:<br />
<br />
* Pick any new user-facing feature you've never heard of before. Try to use it based entirely on the docs. Report results, problems, and suggested doc changes.<br />
* Pick any two or three new features which could be combined somehow ( e.g. join removal and partition joins, or DefaultACLs and column triggers). Try to run a script or query which combines these features. Look for errors or non-spec or confusing behavior. Report both the testing procedure and the results.<br />
* Pick any new feature and an old feature which was either complex (e.g. Tsearch2) or added in the last few versions (e.g. Windowing Functions). Combine them, report how you did it and the results.<br />
<br />
Again, it's important here that you follow up on fixes for any issues you report.<br />
<br />
== How to Test ==<br />
<br />
1. The first time you're going to run a particular test, you might want to post it to pgsql-testers so that other testers can suggest tweaks to make the test more useful.<br />
<br />
2. Script the test so that you can reproduce it.<br />
<br />
3. Run the test and collect the results to a log.<br />
<br />
3.a. Run the test on an older version for comparison, if applicable.<br />
<br />
4. Copy the e-mail template below and post the results using the template to pgsql-testers.<br />
<br />
5. Look for follow-up on your test and respond to it.<br />
<br />
6. Wait for the next release and run the test again.<br />
<br />
== E-mail Template for Submitting Tests ==<br />
<br />
Please paste the following template into the body of e-mails you send into the pgsql-testers list. Try to paste it exactly; we're doing automated parsing of test reports so that we can produce a nice wikitable out of them. Please submit an original e-mail to the list for each test instead of replying to other people's mails.<br />
<br />
=== The Template for Copy & Paste ===<br />
<br />
[TEST REPORT]<br />
<br />
[Release]: <br />
<br />
[Test Type]:<br />
<br />
[Test]:<br />
<br />
[Platform]:<br />
<br />
[Parameters]:<br />
<br />
[Failure]:<br />
<br />
[Results]:<br />
<br />
[Comments]:<br />
<br />
<br />
=== What goes in the fields: ===<br />
<br />
''Please keep all punctuation, brackets, etc.''<br />
<br />
'''[TEST REPORT]''' please keep this header in so that our script knows to start processing.<br />
<br />
'''[Release]:''' the release you tested, preferably in this format: "8.5Alpha1". Required.<br />
<br />
'''[Test Type]:''' Install, application, performance, interface or feature. Required.<br />
<br />
'''[Test]:''' A short description of the test you ran. e.g., "SQLAlchemy Unit Test Suite" or "pgBench" or "Combined DENSE RANK and WITH RECURSIVE". Required.<br />
<br />
'''[Platform]:''' A brief description of the platform you ran the test on. e.g. "MacBook Snow Leapord" or "Linux 16-core Sun 4600 with NAS storage". Optional.<br />
<br />
'''[Parameters]:''' Test parameters you used, if applicable. Optional.<br />
<br />
'''[Failure]:''' Did the test show a compatibility issue, an error, or a performance regression? "Yes" or "No". Optional, defaults to "No".<br />
<br />
'''[Results]:''' A narrative of how you ran the test and what happened. If you experienced errors, please paste detailed error messages. Required.<br />
<br />
'''[Comments]:''' Anything else relevant which wasn't included above. Optional.</div>Theoryhttps://wiki.postgresql.org/index.php?title=FAQ&diff=7099FAQ2009-07-01T16:32:35Z<p>Theory: Add notes about CITEXT.</p>
<hr />
<div>{{Languages}}<br />
== Translations of this Document ==<br />
<br />
* [[Häufig gestellte Fragen|German]]<br />
* [[Perguntas Frequentes|Portuguese]]<br />
* [[Preguntas Frecuentes|Spanish]]<br />
<br />
== General Questions ==<br />
<br />
=== What is PostgreSQL? How is it pronounced? What is Postgres? ===<br />
<br />
PostgreSQL is pronounced Post-Gres-Q-L. (For those curious about how<br />
to say "PostgreSQL", an [http://www.postgresql.org/files/postgresql.mp3 audio file] is available.)<br />
<br />
PostgreSQL is an object-relational database system that has the<br />
features of traditional commercial database systems with enhancements<br />
to be found in next-generation DBMS systems. PostgreSQL is free and<br />
the complete source code is available.<br />
<br />
PostgreSQL development is performed by a team of mostly volunteer<br />
developers spread throughout the world and communicating via the<br />
Internet. It is a community project and is not controlled by any<br />
company. To get involved, see the [[Developer_FAQ | Developer FAQ]].<br />
<br />
Postgres is a widely-used nickname for PostgreSQL. It was the original<br />
name of the project at Berkeley and is strongly preferred over other<br />
nicknames. If you find 'PostgreSQL' hard to pronounce, call it<br />
'Postgres' instead.<br />
<br />
=== Who controls PostgreSQL? ===<br />
<br />
If you are looking for a PostgreSQL gatekeeper, central committee, or<br />
controlling company, give up --- there isn't one. We do have a core<br />
committee and CVS committers, but these groups are more for<br />
administrative purposes than control. The project is directed by the<br />
community of developers and users, which anyone can join. All you need<br />
to do is subscribe to the mailing lists and participate in the<br />
discussions. (See the [[Developer FAQ|Developer's FAQ]] for information on how to get<br />
involved in PostgreSQL development.)<br />
<br />
=== What is the copyright of PostgreSQL? ===<br />
<br />
PostgreSQL is distributed under the classic BSD license. Basically, it<br />
allows users to do anything they want with the code, including<br />
reselling binaries without the source code. The only restriction is<br />
that you not hold us legally liable for problems with the software.<br />
There is also the requirement that this copyright appear in all copies<br />
of the software. Here is the actual BSD license we use:<br />
<br />
PostgreSQL Data Base Management System<br />
<br />
Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group<br />
Portions Copyright (c) 1994-1996 Regents of the University of<br />
California<br />
<br />
Permission to use, copy, modify, and distribute this software and its<br />
documentation for any purpose, without fee, and without a written<br />
agreement is hereby granted, provided that the above copyright notice<br />
and this paragraph and the following two paragraphs appear in all<br />
copies.<br />
<br />
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY<br />
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,<br />
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND<br />
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN<br />
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.<br />
<br />
THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,<br />
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF<br />
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE<br />
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF<br />
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,<br />
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.<br />
<br />
=== What platforms does PostgreSQL support? ===<br />
<br />
In general, any modern Unix-compatible platform should be able to run<br />
PostgreSQL. The platforms that have received recent explicit testing<br />
can be seen in the [http://buildfarm.postgresql.org/ Build farm].<br />
The documentation contains more details about supported platforms at http://www.postgresql.org/docs/current/static/supported-platforms.html.<br />
<br />
PostgreSQL also runs natively on Microsoft Windows NT-based operating<br />
systems like Win2000 SP4, WinXP, and Win2003. A prepackaged installer<br />
is available at http://www.postgresql.org/download/windows.<br />
MSDOS-based versions of Windows (Win95, Win98, WinMe) can run<br />
PostgreSQL using Cygwin.<br />
<br />
=== Where can I get PostgreSQL? ===<br />
<br />
There are binary distributions for various operating systems and platforms; see [http://www.postgresql.org/download our download area].<br />
<br />
The source code can be obtained [http://www.postgresql.org/ftp/ via web browser] or [ftp://ftp.postgresql.org/pub/ through ftp].<br />
<br />
=== What is the most recent release? ===<br />
<br />
The latest release of PostgreSQL is shown on the front page of [http://www.postgresql.org/ our website].<br />
<br />
We typically have a major release every year, with minor releases every few months.<br />
Minor releases are usually made at the same time for all supported major-release branches.<br />
For more about major versus minor releases, see<br />
http://www.postgresql.org/support/versioning.<br />
<br />
=== Where can I get support? ===<br />
<br />
The PostgreSQL community provides assistance to many of its users via<br />
email. The main web site to subscribe to the email lists is<br />
http://www.postgresql.org/community/lists/. The general or bugs lists<br />
are a good place to start.<br />
<br />
The major IRC channel is #postgresql on Freenode (irc.freenode.net).<br />
A Spanish one also<br />
exists on the same network, (#postgresql-es), a French one,<br />
(#postgresqlfr), and a Brazilian one, (#postgresql-br). There is also<br />
a PostgreSQL channel on EFNet.<br />
<br />
A list of commercial support companies is available at<br />
http://www.postgresql.org/support/professional_support.<br />
<br />
=== How do I submit a bug report? ===<br />
<br />
Visit the PostgreSQL bug form at<br />
http://www.postgresql.org/support/submitbug. Also check out our ftp<br />
site ftp://ftp.postgresql.org/pub/ to see if there is a more recent<br />
PostgreSQL version.<br />
<br />
Bugs submitted using the bug form or posted to any PostgreSQL mailing<br />
list typically generates one of the following replies:<br />
* It is not a bug, and why<br />
* It is a known bug and is already on the TODO list<br />
* The bug has been fixed in the current release<br />
* The bug has been fixed but is not packaged yet in an official release<br />
* A request is made for more detailed information:<br />
** Operating system<br />
** PostgreSQL version<br />
** Reproducible test case<br />
** Debugging information<br />
** Debugger backtrace output<br />
* The bug is new. The following might happen:<br />
** A patch is created and will be included in the next major or minor release<br />
** The bug cannot be fixed immediately and is added to the TODO list<br />
<br />
=== How do I find out about known bugs or missing features? ===<br />
<br />
PostgreSQL supports an extended subset of SQL:2003. See our [[Todo|TODO list]]<br />
for known bugs, missing features, and future plans.<br />
<br />
A feature request usually results in one of the following replies:<br />
* The feature is already on the TODO list<br />
* The feature is not desired because:<br />
** It duplicates existing functionality that already follows the SQL standard<br />
** The feature would increase code complexity but add little benefit<br />
** The feature would be insecure or unreliable<br />
* The new feature is added to the TODO list<br />
<br />
PostgreSQL does not use a bug tracking system because we find it more<br />
efficient to respond directly to email and keep the TODO list<br />
up-to-date. In practice, bugs don't last very long in the software,<br />
and bugs that affect a large number of users are fixed rapidly. The<br />
only place to find all changes, improvements, and fixes in a<br />
PostgreSQL release is to read the CVS log messages. Even the release<br />
notes do not list every change made to the software.<br />
<br />
=== What documentation is available? ===<br />
<br />
PostgreSQL includes extensive documentation, including a large manual,<br />
manual pages, and some test examples. See the /doc directory. You can<br />
also browse the manuals online at http://www.postgresql.org/docs.<br />
<br />
There are a number of PostgreSQL<br />
books available for purchase; two of them are also available online. A list of books can be found at<br />
http://www.postgresql.org/docs/books/. One of the most popular ones is the one by Korry & Susan<br />
Douglas.<br />
<br />
There is also a collection of<br />
PostgreSQL technical articles on the <br />
[[Community_Generated_Articles%2C_Guides%2C_and_Documentation | wiki]].<br />
<br />
The command line client program psql has some \d commands to show<br />
information about types, operators, functions, aggregates, etc. - use<br />
\? to display the available commands.<br />
<br />
=== How can I learn SQL? ===<br />
<br />
First, consider the PostgreSQL-specific books mentioned above. Many of<br />
our users also like The Practical SQL Handbook, Bowman, Judith S., et<br />
al., Addison-Wesley. Others like The Complete Reference SQL, Groff et<br />
al., McGraw-Hill.<br />
<br />
There are also many nice tutorials available online:<br />
* http://www.intermedia.net/support/sql/sqltut.shtm<br />
* http://sqlcourse.com<br />
* http://www.w3schools.com/sql/default.asp<br />
* http://mysite.verizon.net/Graeme_Birchall/id1.html<br />
* http://sqlzoo.net<br />
<br />
=== How do I submit a patch or join the development team? ===<br />
<br />
See the [[Developer FAQ|Developer's FAQ]].<br />
<br />
=== How does PostgreSQL compare to other DBMSs? ===<br />
<br />
There are several ways of measuring software: features, performance,<br />
reliability, support, and price.<br />
<br />
==== Features ====<br />
<br />
PostgreSQL has most features present in large commercial DBMSs,<br />
like transactions, subselects, triggers, views, foreign key<br />
referential integrity, and sophisticated locking. We have some<br />
features they do not have, like user-defined types,<br />
inheritance, rules, and multi-version concurrency control to<br />
reduce lock contention.<br />
<br />
==== Performance ====<br />
<br />
PostgreSQL's performance is comparable to other commercial and<br />
open source databases. It is faster for some things, slower for<br />
others. Our performance is usually +/-10% compared to other databases.<br />
<br />
==== Reliability ====<br />
<br />
We realize that a DBMS must be reliable, or it is worthless. We<br />
strive to release well-tested, stable code that has a minimum<br />
of bugs. Each release has at least one month of beta testing,<br />
and our release history shows that we can provide stable, solid<br />
releases that are ready for production use. We believe we<br />
compare favorably to other database software in this area.<br />
<br />
==== Support ====<br />
<br />
Our mailing lists provide contact with a large group of<br />
developers and users to help resolve any problems encountered.<br />
While we cannot guarantee a fix, commercial DBMSs do not always<br />
supply a fix either. Direct access to developers, the user<br />
community, manuals, and the source code often make PostgreSQL<br />
support superior to other DBMSs. There is commercial<br />
per-incident support available for those who need it. (See [[#Where_can_I_get_support.3F | section 1.7]]).<br />
<br />
==== Price ====<br />
<br />
We are free for all use, both commercial and non-commercial.<br />
You can add our code to your product with no limitations,<br />
except those outlined in our BSD-style license stated above. <br />
<br />
=== Can PostgreSQL be embedded? ===<br />
<br />
PostgreSQL is designed as a client/server architecture, which requires<br />
separate processes for each client and server, and various helper<br />
processes. Many embedded architectures can support such requirements.<br />
However, if your embedded architecture requires the database server to<br />
run inside the application process, you cannot use Postgres and should<br />
select a lighter-weight database solution.<br />
<br />
=== How do I unsubscribe from the PostgreSQL email lists? How do I avoid receiving duplicate emails? ===<br />
<br />
The PostgreSQL Majordomo page allows subscribing or unsubscribing from<br />
any of the PostgreSQL email lists. (You might need to have your<br />
Majordomo password emailed to you to log in.)<br />
<br />
All PostgreSQL email lists are configured so a group reply goes to the<br />
email list and the original email author. This is done so users<br />
receive the quickest possible email replies. If you would prefer not<br />
to receive duplicate email from the list in cases where you already<br />
receive an email directly, check eliminatecc from the Majordomo Change<br />
Settings page. You can also prevent yourself from receiving copies of<br />
emails you post to the lists by unchecking selfcopy.<br />
<br />
== User Client Questions ==<br />
<br />
=== What interfaces are available for PostgreSQL? ===<br />
<br />
The PostgreSQL install includes only the C and embedded C interfaces.<br />
All other interfaces are independent projects that are downloaded<br />
separately; being separate allows them to have their own release<br />
schedule and development teams.<br />
<br />
Some programming languages like PHP include an interface to<br />
PostgreSQL. Interfaces for languages like Perl, TCL, Python, and many<br />
others are available at http://pgfoundry.org.<br />
<br />
=== What tools are available for using PostgreSQL with Web pages? ===<br />
<br />
A nice introduction to Database-backed Web pages can be seen at:<br />
http://www.webreview.com<br />
<br />
For Web integration, PHP (http://www.php.net) is an excellent<br />
interface.<br />
<br />
For complex cases, many use the Perl and DBD::Pg with CGI.pm or<br />
mod_perl.<br />
<br />
=== Does PostgreSQL have a graphical user interface? ===<br />
<br />
There are a large number of GUI Tools that are available for<br />
PostgreSQL from both commercial and open source developers. A detailed<br />
list can be found in the [[Community Guide to PostgreSQL GUI Tools]].<br />
<br />
== Administrative Questions ==<br />
<br />
=== How do I install PostgreSQL somewhere other than /usr/local/pgsql? ===<br />
<br />
Specify the --prefix option when running configure.<br />
<br />
=== How do I control connections from other hosts? ===<br />
<br />
By default, PostgreSQL only allows connections from the local machine<br />
using Unix domain sockets or TCP/IP connections. Other machines will<br />
not be able to connect unless you modify listen_addresses in the<br />
postgresql.conf file, enable host-based authentication by modifying<br />
the $PGDATA/pg_hba.conf file, and restart the database server.<br />
<br />
=== How do I tune the database engine for better performance? ===<br />
<br />
There are three major areas for potential performance improvement:<br />
<br />
==== Query Changes ====<br />
This involves modifying queries to obtain better performance:<br />
<br />
* Creation of indexes, including expression and partial indexes<br />
* Use of COPY instead of multiple INSERTs<br />
* Grouping of multiple statements into a single transaction to reduce commit overhead<br />
* Use of CLUSTER when retrieving many rows from an index<br />
* Use of LIMIT for returning a subset of a query's output<br />
* Use of Prepared queries<br />
* Use of ANALYZE to maintain accurate optimizer statistics<br />
* Regular use of VACUUM or pg_autovacuum<br />
* Dropping of indexes during large data changes<br />
<br />
==== Server Configuration ====<br />
A number of postgresql.conf settings affect performance. For<br />
more details, see Administration Guide/Server Run-time<br />
Environment/Run-time Configuration.<br />
<br />
==== Hardware Selection ====<br />
The effect of hardware on performance is detailed in<br />
http://www.powerpostgresql.com/PerfList/ and<br />
http://momjian.us/main/writings/pgsql/hw_performance/index.html.<br />
<br />
=== What debugging features are available? ===<br />
<br />
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.<br />
<br />
=== Why do I get "Sorry, too many clients" when trying to connect? ===<br />
<br />
You have reached the default limit of 100 database sessions. You need<br />
to increase the server's limit on how many concurrent backend<br />
processes it can start by changing the max_connections value in<br />
postgresql.conf and restarting the server.<br />
<br />
=== What is the upgrade process for PostgreSQL? ===<br />
<br />
See http://www.postgresql.org/support/versioning for a general<br />
discussion about upgrading, and<br />
http://www.postgresql.org/docs/current/static/install-upgrading.html<br />
for specific instructions.<br />
<br />
=== Will PostgreSQL handle recent daylight saving time changes in various countries? ===<br />
<br />
PostgreSQL releases 8.0 and up depend on the widely-used tzdata database<br />
(also called the zoneinfo database or the [http://www.twinsun.com/tz/tz-link.htm Olson timezone database]) for<br />
daylight savings information. To deal with a DST law change that affects you,<br />
install a new tzdata file set and restart the server.<br />
<br />
All PostgreSQL update releases include the latest available tzdata files,<br />
so keeping up-to-date on minor releases for your major version is usually<br />
sufficient for this.<br />
<br />
On platforms that receive regular software updates including new tzdata files,<br />
it may be more convenient to rely on the system's copy of the tzdata files.<br />
This is possible as a compile-time option. Most Linux distributions choose<br />
this approach for their pre-built versions of PostgreSQL.<br />
<br />
PostgreSQL releases before 8.0 always rely on the operating system's timezone<br />
information.<br />
<br />
=== What computer hardware should I use? ===<br />
<br />
Because PC hardware is mostly compatible, people tend to believe that<br />
all PC hardware is of equal quality. It is not. ECC RAM, SCSI, and<br />
quality motherboards are more reliable and have better performance<br />
than less expensive hardware. PostgreSQL will run on almost any<br />
hardware, but if reliability and performance are important it is wise<br />
to research your hardware options thoroughly. A disk controller with a<br />
battery-backed cache is also useful. Our email lists can be used to<br />
discuss hardware options and tradeoffs.<br />
<br />
== Operational Questions ==<br />
<br />
=== How do I SELECT only the first few rows of a query? A random row? ===<br />
<br />
To retrieve only a few rows, if you know at the number of rows needed<br />
at the time of the SELECT use LIMIT . If an index matches the ORDER BY<br />
it is possible the entire query does not have to be executed. If you<br />
don't know the number of rows at SELECT time, use a cursor and FETCH.<br />
<br />
To SELECT a random row, use:<br />
SELECT col<br />
FROM tab<br />
ORDER BY random()<br />
LIMIT 1;<br />
<br />
See also this [http://blog.rhodiumtoad.org.uk/2009/03/08/selecting-random-rows-from-a-table/ blog entry by Andrew Gierth]<br />
that has more information on this topic.<br />
<br />
=== 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? ===<br />
<br />
Use the \dt command to see tables in psql. For a complete list of<br />
commands inside psql you can use \?. Alternatively you can read the<br />
source code for psql in file pgsql/src/bin/psql/describe.c, it<br />
contains SQL commands that generate the output for psql's backslash<br />
commands. You can also start psql with the -E option so it will print<br />
out the queries it uses to execute the commands you give. PostgreSQL<br />
also provides an SQL compliant INFORMATION SCHEMA interface you can<br />
query to get information about the database.<br />
<br />
There are also system tables beginning with pg_ that describe these<br />
too.<br />
<br />
Use psql -l will list all databases.<br />
<br />
Also try the file pgsql/src/tutorial/syscat.source. It illustrates<br />
many of the SELECTs needed to get information from the database system<br />
tables.<br />
<br />
=== How do you change a column's data type? ===<br />
<br />
Changing the data type of a column can be done easily in 8.0 and later<br />
with ALTER TABLE ALTER COLUMN TYPE.<br />
<br />
In earlier releases, do this:<br />
BEGIN;<br />
ALTER TABLE tab ADD COLUMN new_col new_data_type;<br />
UPDATE tab SET new_col = CAST(old_col AS new_data_type);<br />
ALTER TABLE tab DROP COLUMN old_col;<br />
COMMIT;<br />
<br />
You might then want to do VACUUM FULL tab to reclaim the disk space<br />
used by the expired rows.<br />
<br />
=== What is the maximum size for a row, a table, and a database? ===<br />
<br />
These are the limits:<br />
<br />
Maximum size for a database? unlimited (32 TB databases exist)<br />
Maximum size for a table? 32 TB<br />
Maximum size for a row? 400 GB<br />
Maximum size for a field? 1 GB<br />
Maximum number of rows in a table? unlimited<br />
Maximum number of columns in a table? 250-1600 depending on column types<br />
Maximum number of indexes on a table? unlimited<br />
<br />
Of course, these are not actually unlimited, but limited to available<br />
disk space and memory/swap space. Performance may suffer when these<br />
values get unusually large.<br />
<br />
The maximum table size of 32 TB does not require large file support<br />
from the operating system. Large tables are stored as multiple 1 GB<br />
files so file system size limits are not important.<br />
<br />
The maximum table size, row size, and maximum number of columns can be<br />
quadrupled by increasing the default block size to 32k. The maximum<br />
table size can also be increased using table partitioning.<br />
<br />
One limitation is that indexes can not be created on columns longer<br />
than about 2,000 characters. Fortunately, such indexes are rarely<br />
needed. Uniqueness is best guaranteed by a function index of an MD5<br />
hash of the long column, and full text indexing allows for searching<br />
of words within the column.<br />
<br />
=== How much database disk space is required to store data from a typical text file? ===<br />
<br />
A PostgreSQL database may require up to five times the disk space to<br />
store data from a text file.<br />
<br />
As an example, consider a file of 100,000 lines with an integer and<br />
text description on each line. Suppose the text string averages<br />
twenty bytes in length. The flat file would be 2.8 MB. The size of the<br />
PostgreSQL database file containing this data can be estimated as 5.2<br />
MB:<br />
24 bytes: each row header (approximate)<br />
24 bytes: one int field and one text field<br />
+ 4 bytes: pointer on page to tuple<br />
----------------------------------------<br />
52 bytes per row<br />
<br />
The data page size in PostgreSQL is 8192 bytes (8 KB), so:<br />
<br />
8192 bytes per page<br />
------------------- = 158 rows per database page (rounded down)<br />
52 bytes per row<br />
<br />
100000 data rows<br />
------------------ = 633 database pages (rounded up)<br />
158 rows per page<br />
<br />
633 database pages * 8192 bytes per page = 5,185,536 bytes (5.2 MB)<br />
<br />
Indexes do not require as much overhead, but do contain the data that<br />
is being indexed, so they can be large also.<br />
<br />
NULLs are stored as bitmaps, so they use very little space.<br />
<br />
Note that long values may be compressed transparently.<br />
<br />
See also this presentation on the topic: [[Image:How_Long_Is_a_String.pdf]].<br />
<br />
=== Why are my queries slow? Why don't they use my indexes? ===<br />
<br />
Indexes are not used by every query. Indexes are used only if the<br />
table is larger than a minimum size, and the query selects only a<br />
small percentage of the rows in the table. This is because the random<br />
disk access caused by an index scan can be slower than a straight read<br />
through the table, or sequential scan.<br />
<br />
To determine if an index should be used, PostgreSQL must have<br />
statistics about the table. These statistics are collected using<br />
VACUUM ANALYZE, or simply ANALYZE. Using statistics, the optimizer<br />
knows how many rows are in the table, and can better determine if<br />
indexes should be used. Statistics are also valuable in determining<br />
optimal join order and join methods. Statistics collection should be<br />
performed periodically as the contents of the table change.<br />
<br />
Indexes are normally not used for ORDER BY or to perform joins. A<br />
sequential scan followed by an explicit sort is usually faster than an<br />
index scan of a large table. However, LIMIT combined with ORDER BY<br />
often will use an index because only a small portion of the table is<br />
returned.<br />
<br />
If you believe the optimizer is incorrect in choosing a sequential<br />
scan, use SET enable_seqscan TO 'off' and run query again to see if an<br />
index scan is indeed faster.<br />
<br />
When using wild-card operators such as LIKE or ~, indexes can only be<br />
used in certain circumstances:<br />
<br />
* The beginning of the search string must be anchored to the start of the string, i.e.<br />
** LIKE patterns must not start with % or _.<br />
** ~ (regular expression) patterns must start with ^.<br />
<br />
* The search string can not start with a character class, e.g. [a-e].<br />
<br />
* 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]].<br />
<br />
* 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.<br />
<br />
It is also possible to use full text indexing for word searches.<br />
<br />
=== How do I see how the query optimizer is evaluating my query? ===<br />
<br />
This is done with the EXPLAIN command; see [[Using EXPLAIN]].<br />
<br />
=== How do I change the sort ordering of textual data? ===<br />
<br />
PostgreSQL sorts textual data according to the ordering that is defined by the current locale, which is selected during initdb.<br />
(In 8.4 and up it will be possible to select a different locale when creating a new database.)<br />
If you don't like the ordering then you need to use a different locale.<br />
In particular, most locales other than "C" sort according to dictionary order, which largely ignores punctuation and spacing.<br />
If that's not what you want then you need "C" locale.<br />
<br />
=== How do I perform regular expression searches and case-insensitive regular expression searches? How do I use an index for case-insensitive searches? ===<br />
<br />
The ~ operator does regular expression matching, and ~* does<br />
case-insensitive regular expression matching. The case-insensitive<br />
variant of LIKE is called ILIKE.<br />
<br />
Case-insensitive equality comparisons are normally expressed as:<br />
SELECT *<br />
FROM tab<br />
WHERE lower(col) = 'abc';<br />
<br />
This will not use a standard index on "col". However, if you create an<br />
expression index on "lower(col)", it will be used:<br />
CREATE INDEX tabindex ON tab (lower(col));<br />
<br />
If the above index is created as UNIQUE, then the column can store<br />
upper and lowercase characters, but it cannot contain identical values that<br />
differ only in case. To force a particular case to be stored in the<br />
column, use a CHECK constraint or a trigger.<br />
<br />
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].<br />
<br />
=== 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? ===<br />
<br />
You can test the value with IS NULL or IS NOT NULL, like this:<br />
SELECT *<br />
FROM tab<br />
WHERE col IS NULL;<br />
<br />
Concatenating a NULL with something else produces another NULL.<br />
If that's not what you want, you can replace the NULL(s) using<br />
COALESCE(), like this:<br />
<nowiki>SELECT COALESCE(col1, '') || COALESCE(col2, '')</nowiki><br />
FROM tab;<br />
<br />
To sort by the NULL status, use an IS NULL or IS NOT NULL test<br />
in your ORDER BY clause. Things that are true will sort higher than<br />
things that are false, so the following will put NULL entries at the<br />
front of the output:<br />
SELECT *<br />
FROM tab<br />
ORDER BY (col IS NOT NULL), col;<br />
<br />
In PostgreSQL 8.3 and up, you can also control sort ordering of NULLs<br />
using the recently-standardized NULLS FIRST/NULLS LAST modifiers,<br />
like this:<br />
SELECT *<br />
FROM tab<br />
ORDER BY col NULLS FIRST;<br />
<br />
=== What is the difference between the various character types? ===<br />
<br />
{| border="1"<br />
!Type<br />
!Internal Name<br />
!Notes<br />
|-<br />
|VARCHAR(n) <br />
|varchar<br />
|size specifies maximum length, no padding<br />
|- <br />
|CHAR(n)<br />
|bpchar<br />
|blank-padded to the specified fixed length<br />
|-<br />
|TEXT<br />
|text<br />
|no specific upper limit on length<br />
|-<br />
|BYTEA<br />
|bytea<br />
|variable-length byte array (null-byte safe)<br />
|-<br />
|"char" (with the quotes)<br />
|char<br />
|one byte<br />
|}<br />
<br />
You will see the internal name when examining system catalogs and in<br />
some error messages.<br />
<br />
The first four types above are "varlena" types (i.e., the field length<br />
is explicitly stored on disk, followed by the data). Thus the actual<br />
space used is slightly greater than the expected size. However, long<br />
values are also subject to compression, so the space on disk might<br />
also be less than expected.<br />
<br />
VARCHAR(n) is best when storing variable-length strings if a specific<br />
upper limit on the string length is required by the application.<br />
TEXT is for strings of "unlimited" length (though all fields in PostgreSQL<br />
are subject to a maximum value length of one gigabyte).<br />
<br />
CHAR(n) is for storing strings that are all the same length. CHAR(n)<br />
pads with blanks to the specified length, while VARCHAR(n) only stores<br />
the characters supplied. BYTEA is for storing binary data,<br />
particularly values that include zero bytes. All these types have similar<br />
performance characteristics, except that the blank-padding involved<br />
in CHAR(n) requires additional storage and some extra runtime.<br />
<br />
The "char" type (the quotes are required to distinguish it from CHAR(n))<br />
is a specialized datatype that can store exactly one byte. It is found in<br />
the system catalogs but its use in user tables is generally discouraged.<br />
<br />
=== How do I create a serial/auto-incrementing field? ===<br />
<br />
PostgreSQL supports a SERIAL data type. Actually, this isn't quite<br />
a real type. It's a shorthand for creating an integer column that<br />
is fed from a sequence.<br />
<br />
For example, this:<br />
CREATE TABLE person (<br />
id SERIAL,<br />
name TEXT<br />
);<br />
is automatically translated into this:<br />
CREATE SEQUENCE person_id_seq;<br />
CREATE TABLE person (<br />
id INTEGER NOT NULL DEFAULT nextval('person_id_seq'),<br />
name TEXT<br />
);<br />
<br />
The automatically created sequence is named ''table''_''serialcolumn''_seq,<br />
where ''table'' and ''serialcolumn'' are the names of the table and SERIAL<br />
column, respectively. See the CREATE SEQUENCE manual page for more<br />
information about sequences.<br />
<br />
There is also BIGSERIAL, which is like SERIAL except that the resulting<br />
column is of type BIGINT instead of INTEGER. Use this type if you think<br />
that you might need more than 2 billion serial values over the lifespan<br />
of the table.<br />
<br />
=== How do I get the value of a SERIAL insert? ===<br />
<br />
The simplest way is to retrieve the assigned SERIAL value with<br />
RETURNING. Using the example table in the previous question, it would look like this:<br />
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;<br />
<br />
You can also call nextval() and use that value in the INSERT, or call<br />
currval() after the INSERT.<br />
<br />
=== Doesn't currval() lead to a race condition with other users? ===<br />
<br />
No. currval() returns the latest sequence value assigned by your session,<br />
independently of what is happening in other sessions.<br />
<br />
=== Why are there gaps in the numbering of my sequence/SERIAL column? Why aren't my sequence numbers reused on transaction abort? ===<br />
<br />
To improve concurrency, sequence values are given out to running<br />
transactions on-demand; the sequence object is not kept locked but is<br />
immediately available for another transaction to get another sequence<br />
value. This causes gaps in numbering from aborted transactions.<br />
<br />
=== What is an OID? ===<br />
<br />
If a table is created WITH OIDS, each row includes an OID column that is automatically filled in during INSERT.<br />
OIDs are sequentially assigned 4-byte integers. Initially they are unique<br />
across the entire installation. However, the OID counter wraps around at 4 billion,<br />
and after that OIDs may be duplicated.<br />
<br />
It is possible to prevent duplication of OIDs within a single table by<br />
creating a unique index on the OID column (but note that the WITH OIDS<br />
clause doesn't by itself create such an index).<br />
The system checks the index to see if a newly<br />
generated OID is already present, and if so generates a new OID and<br />
repeats. This works well so long as no OID-containing table has<br />
more than a small fraction of 4 billion rows. <br />
<br />
PostgreSQL uses OIDs for object identifiers in the system catalogs,<br />
where the size limit is unlikely to be a problem.<br />
<br />
To uniquely number rows in user tables, it is best to use SERIAL<br />
rather than an OID column, or BIGSERIAL if the table is expected to<br />
have more than 2 billion entries over its lifespan.<br />
<br />
=== What is a CTID? ===<br />
<br />
CTIDs identify specific physical rows by their block and<br />
offset positions within a table.<br />
They are used by index entries to point to physical rows.<br />
A logical row's CTID changes when it is updated, so the CTID<br />
cannot be used as a long-term row identifier. But it is sometimes<br />
useful to identify a row within a transaction when no competing<br />
update is expected.<br />
<br />
=== Why do I get the error "ERROR: Memory exhausted in AllocSetAlloc()"? ===<br />
<br />
You probably have run out of virtual memory on your system, or your<br />
kernel has a low limit for certain resources. Try this before starting<br />
the server:<br />
ulimit -d 262144<br />
limit datasize 256m<br />
<br />
Depending on your shell, only one of these may succeed, but it will<br />
set your process data segment limit much higher and perhaps allow the<br />
query to complete. This command applies to the current process, and<br />
all subprocesses created after the command is run. If you are having a<br />
problem with the SQL client because the backend is returning too much<br />
data, try it before starting the client.<br />
<br />
=== How do I tell what PostgreSQL version I am running? ===<br />
<br />
Run this query: SELECT version();<br />
<br />
=== Is there a way to leave an audit trail of database operations? ===<br />
<br />
There's nothing built-in, but it's not too difficult to build such<br />
facilities yourself.<br />
<br />
Simple example right in the official docs:<br />
http://www.postgresql.org/docs/8.3/static/plpgsql-trigger.html#PLPGSQL-TRIGGER-AUDIT-EXAMPLE<br />
<br />
Project targeting this feature: http://pgfoundry.org/projects/tablelog/<br />
<br />
Background information and other sample implementations: <br />
http://it.toolbox.com/blogs/database-soup/simple-data-auditing-19014<br />
http://www.go4expert.com/forums/showthread.php?t=7252<br />
http://www.alberton.info/postgresql_table_audit.html<br />
<br />
=== How do I create a column that will default to the current time? ===<br />
<br />
Use CURRENT_TIMESTAMP:<br />
CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );<br />
<br />
=== How do I perform an outer join? ===<br />
<br />
PostgreSQL supports outer joins using the SQL standard syntax. Here<br />
are two examples:<br />
SELECT *<br />
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);<br />
<br />
or<br />
SELECT *<br />
FROM t1 LEFT OUTER JOIN t2 USING (col);<br />
<br />
These identical queries join t1.col to t2.col, and also return any<br />
unjoined rows in t1 (those with no match in t2). A RIGHT join would<br />
add unjoined rows of t2. A FULL join would return the matched rows<br />
plus all unjoined rows from t1 and t2. The word OUTER is optional and<br />
is assumed in LEFT, RIGHT, and FULL joins. Ordinary joins are called<br />
INNER joins.<br />
<br />
=== How do I perform queries using multiple databases? ===<br />
<br />
There is no way to query a database other than the current one.<br />
Because PostgreSQL loads database-specific system catalogs, it is<br />
uncertain how a cross-database query should even behave.<br />
<br />
contrib/dblink allows cross-database queries using function calls. Of<br />
course, a client can also make simultaneous connections to different<br />
databases and merge the results on the client side.<br />
<br />
=== How do I return multiple rows or columns from a function? ===<br />
<br />
It is easy using set-returning functions,<br />
[[Return more than one row of data from PL/pgSQL functions]].<br />
<br />
=== Why do I get "relation with OID ##### does not exist" errors when accessing temporary tables in PL/PgSQL functions? ===<br />
<br />
In PostgreSQL versions < 8.3, PL/PgSQL caches function scripts, and an<br />
unfortunate side effect is that if a PL/PgSQL function accesses a<br />
temporary table, and that table is later dropped and recreated, and<br />
the function called again, the function will fail because the cached<br />
function contents still point to the old temporary table. The solution<br />
is to use EXECUTE for temporary table access in PL/PgSQL. This will<br />
cause the query to be reparsed every time.<br />
<br />
This problem does not occur in PostgreSQL 8.3 and later.<br />
<br />
=== What replication solutions are available? ===<br />
<br />
Though "replication" is a single term, there are several technologies<br />
for doing replication, with advantages and disadvantages for each.<br />
Our documentation contains a good introduction to this topic at<br />
http://www.postgresql.org/docs/8.3/static/high-availability.html and a<br />
grid listing replication software and features is at<br />
[[Replication, Clustering, and Connection Pooling]]<br />
<br />
Master/slave replication allows a single master to receive read/write<br />
queries, while slaves can only accept read/SELECT queries. The most<br />
popular freely available master-slave PostgreSQL replication solution<br />
is Slony-I.<br />
<br />
Multi-master replication allows read/write queries to be sent to<br />
multiple replicated computers. This capability also has a severe<br />
impact on performance due to the need to synchronize changes between<br />
servers. PGCluster is the most popular such solution freely available<br />
for PostgreSQL.<br />
<br />
There are also commercial and hardware-based replication solutions<br />
available supporting a variety of replication models.<br />
<br />
=== Why are my table and column names not recognized in my query? Why is capitalization not preserved? ===<br />
<br />
The most common cause of unrecognized names is the use of<br />
double-quotes around table or column names during table creation. When<br />
double-quotes are used, table and column names (called identifiers)<br />
are stored case-sensitive, meaning you must use double-quotes when<br />
referencing the names in a query. Some interfaces, like pgAdmin,<br />
automatically double-quote identifiers during table creation. So, for<br />
identifiers to be recognized, you must either:<br />
<br />
* Avoid double-quoting identifiers when creating tables<br />
* Use only lowercase characters in identifiers<br />
* Double-quote identifiers when referencing them in queries<br />
<br />
<br />
[[Category:FAQ]]</div>Theoryhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-09&diff=1919CommitFest 2008-092008-08-11T17:44:11Z<p>Theory: </p>
<hr />
<div>= CommitFest =<br />
<br />
This is the page for CommitFest starting 2008 September<br />
<br />
{{CommitFestOpen}}<br />
<br />
{{CommitFestSection|Pending patches}}<br />
<br />
{{patch|20080803.114711.73374027.t-ishii@sraoss.co.jp|WITH RECURSIVE|Yoshiyuki Asaba|status=WIP}}<br />
{{comment|tgl|still hoping for an implementation README before starting serious review}}<br />
<br />
{{patch|e51f66da0805141329p3604a350mef9e997a4379b62f@mail.gmail.com|PL/Proxy|Marko Kreen|reviewers=Greg Stark}}<br />
{{comment|David Fetter|Next revision of the {{messageLink|e51f66da0806280636p1c76a953p37eeb72ecfb0b3a8@mail.gmail.com|patch here.}}}}<br />
{{comment|Zdeněk Kotala|{{messageLink|16790.1216669380@sss.pgh.pa.us|Discussion}} about integration into to the core.}} <br />
<br />
{{patch|485A3F20.1080907@cybertec.at|posix fadvises|Zoltan Boszormenyi, Greg Stark|reviewers=Greg Smith, Abhijit Menon-Sen}}<br />
{{comment|Greg Smith|needs performance testing, {{messageLink|Pine.GSO.4.64.0807150045030.11155@westnet.com|here's the plan}}, will continue review throughput August}}<br />
<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei|reviewers=Peter Eisentraut, Abhijit Menon-Sen}}<br />
{{comment|Peter|checking with Solaris engineers about compatibility with Solaris TX; will continue review throughout August}}<br />
{{comment|KaiGai|{{messageLink|488F0C02.4020708@ak.jp.nec.com|latest patch versions}}}}<br />
<br />
<br />
{{patch|1215263027.4051.299.camel@ebony.site|pgbench minor fixes|Simon Riggs}}<br />
<br />
{{patch|1215274649.4051.319.camel@ebony.site|psql help corrections|Simon Riggs}}<br />
<br />
{{patch|1215502581.4051.674.camel@ebony.site|suset log temp files|Simon Riggs}}<br />
<br />
{{patch|48325386.2010506@esilo.com|libpq object hooks|Merlin Moncure, Andrew Chernow|status=WIP}}<br />
<br />
{{patch|603c8f070807261444s133fb281sf34d069ab5b4c0b@mail.gmail.com|Add a separate TRUNCATE permission|Robert Haas}}<br />
<br />
{{patch|2FD031D4-7B94-4EEF-9C4D-34A77F3FE256@kineticode.com|Test citext casts|David Wheeler}}<br />
{{comment|David Wheeler|Next revision of the {{messageLink|F721EFF1-553C-4E25-A293-7BD08D6957F4@kineticode.com|patch here.}}}}<br />
{{patch|20080722055735.GW30869@sonic.net|pg_dumpall lock timeout|David Gould}}<br />
{{comment|David Gould|this was part of the pg_dump lock timeout patch that was committed in July, but apparently got missed.}}<br />
<br />
{{patch|20080805150620.A197.52131E4D@oss.ntt.co.jp|NDirectFileRead and Write|Takahiro Itagaki}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Committed patches}}<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Returned with Feedback}}<br />
{{CommitFestEndSection}}</div>Theoryhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-09&diff=1912CommitFest 2008-092008-08-11T04:00:19Z<p>Theory: </p>
<hr />
<div>= CommitFest =<br />
<br />
This is the page for CommitFest starting 2008 September<br />
<br />
{{CommitFestOpen}}<br />
<br />
{{CommitFestSection|Pending patches}}<br />
<br />
{{patch|20080803.114711.73374027.t-ishii@sraoss.co.jp|WITH RECURSIVE|Yoshiyuki Asaba|status=WIP}}<br />
{{comment|tgl|still hoping for an implementation README before starting serious review}}<br />
<br />
{{patch|e51f66da0805141329p3604a350mef9e997a4379b62f@mail.gmail.com|PL/Proxy|Marko Kreen|reviewers=Greg Stark}}<br />
{{comment|David Fetter|Next revision of the {{messageLink|e51f66da0806280636p1c76a953p37eeb72ecfb0b3a8@mail.gmail.com|patch here.}}}}<br />
{{comment|Zdeněk Kotala|{{messageLink|16790.1216669380@sss.pgh.pa.us|Discussion}} about integration into to the core.}} <br />
<br />
{{patch|485A3F20.1080907@cybertec.at|posix fadvises|Zoltan Boszormenyi, Greg Stark|reviewers=Greg Smith, Abhijit Menon-Sen}}<br />
{{comment|Greg Smith|needs performance testing, {{messageLink|Pine.GSO.4.64.0807150045030.11155@westnet.com|here's the plan}}, will continue review throughput August}}<br />
<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei|reviewers=Peter Eisentraut, Abhijit Menon-Sen}}<br />
{{comment|Peter|checking with Solaris engineers about compatibility with Solaris TX; will continue review throughout August}}<br />
{{comment|KaiGai|{{messageLink|488F0C02.4020708@ak.jp.nec.com|latest patch versions}}}}<br />
<br />
<br />
{{patch|1215263027.4051.299.camel@ebony.site|pgbench minor fixes|Simon Riggs}}<br />
<br />
{{patch|1215274649.4051.319.camel@ebony.site|psql help corrections|Simon Riggs}}<br />
<br />
{{patch|1215502581.4051.674.camel@ebony.site|suset log temp files|Simon Riggs}}<br />
<br />
{{patch|48325386.2010506@esilo.com|libpq object hooks|Merlin Moncure, Andrew Chernow|status=WIP}}<br />
<br />
{{patch|603c8f070807261444s133fb281sf34d069ab5b4c0b@mail.gmail.com|Add a separate TRUNCATE permission|Robert Haas}}<br />
<br />
{{patch|2FD031D4-7B94-4EEF-9C4D-34A77F3FE256@kineticode.com|Test citext casts|David Wheeler}}<br />
{{comment|David Wheeler|Next revision of the {{messageLink|08157471-DF74-46F2-B34A-6D34C160C1DA@kineticode.com|patch here.}}}}<br />
{{patch|20080722055735.GW30869@sonic.net|pg_dumpall lock timeout|David Gould}}<br />
{{comment|David Gould|this was part of the pg_dump lock timeout patch that was committed in July, but apparently got missed.}}<br />
<br />
{{patch|20080805150620.A197.52131E4D@oss.ntt.co.jp|NDirectFileRead and Write|Takahiro Itagaki}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Committed patches}}<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Returned with Feedback}}<br />
{{CommitFestEndSection}}</div>Theoryhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-09&diff=1867CommitFest 2008-092008-08-04T18:09:22Z<p>Theory: Added citext cast testing patch.</p>
<hr />
<div>= CommitFest =<br />
<br />
This is the page for CommitFest starting 2008 September<br />
<br />
{{CommitFestOpen}}<br />
<br />
{{CommitFestSection|Pending patches}}<br />
<br />
{{patch|1215263027.4051.299.camel@ebony.site|pgbench minor fixes|Simon Riggs}}<br />
<br />
{{patch|1215274649.4051.319.camel@ebony.site|psql help corrections|Simon Riggs}}<br />
<br />
{{patch|1215502581.4051.674.camel@ebony.site|suset log temp files|Simon Riggs}}<br />
<br />
{{patch|48325386.2010506@esilo.com|libpq object hooks|Merlin Moncure, Andrew Chernow|status=WIP}}<br />
<br />
{{patch|603c8f070807261444s133fb281sf34d069ab5b4c0b@mail.gmail.com|Add a separate TRUNCATE permission|Robert Haas}}<br />
<br />
{{patch|2FD031D4-7B94-4EEF-9C4D-34A77F3FE256@kineticode.com|Test citext casts|David Wheeler}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Committed patches}}<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Returned with Feedback}}<br />
{{CommitFestEndSection}}</div>Theoryhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-07&diff=1770CommitFest 2008-072008-07-16T17:55:49Z<p>Theory: </p>
<hr />
<div>= CommitFest =<br />
<br />
This is the page for CommitFest starting July 2008<br />
<br />
{{CommitFestCurrent}}<br />
<br />
{{CommitFestSection|Pending patches}}<br />
<br />
{{patch|20080511113047.GV5673@sonic.net|pg_dump lock timeout|Dave Gould|status=Waiting on response|reviewers=David Fetter, Stephen Frost}}<br />
{{review|20080703013346.GP31154@tamriel.snowman.net|Stephen Frost|Couple of minor changes requested, otherwise good}}<br />
{{comment|Stephen Frost|Dave Gould will make the changes agreed on and provide an update.}}<br />
<br />
{{patch|20080518.205129.86993930.t-ishii@sraoss.co.jp|WITH RECURSIVE|Yoshiyuki Asaba|status=Pending Review|reviewers=David Fetter}}<br />
{{review|20080518.205129.86993930.t-ishii@sraoss.co.jp|David Fetter|Updated with fixes from Yoshiyuki Asaba and Michael Meskes}}<br />
{{comment|alvherre|There's a long TODO list {{messageLink|20080527.101013.85412760.t-ishii@sraoss.co.jp|here}}}}<br />
{{comment|David Fetter|update patch {{messageLink|20080702231101.GH19610@fetter.org|here}}}}<br />
<br />
{{patch|482F955D.1050600@sun.com|DTrace probe additions|Robert Lor|reviewers=Zdeněk Kotala|status=Waiting for response}}<br />
{{comment|Theo Schlossnagle|another {{messageLink|BB9C10CC-EF5F-442F-949F-2D1E9C6F7A85@omniti.com|DTrace probe patch}}}}<br />
{{comment|Zdeněk Kotala|Robert Treat sent {{messageLink|200807022300.19538.xzilla@users.sourceforge.net|merge of DTrace probe patches}}}}<br />
{{comment|Zdeněk Kotala|Review is {{messageLink|486E35CE.4070309@sun.com|there}} and [http://reviewdemo.postgresql.org/r/25/ here]. Merged patch does not work.}}<br />
<br />
{{patch|e51f66da0805141329p3604a350mef9e997a4379b62f@mail.gmail.com|PL/Proxy|Marko Kreen|reviewers=Greg Stark}}<br />
{{comment|David Fetter|Next revision of the {{messageLink|e51f66da0806280636p1c76a953p37eeb72ecfb0b3a8@mail.gmail.com|patch here.}}}}<br />
<br />
{{patch|c2d9e70e0805232156p20dbe2b9j2a88d35f951d625e@mail.gmail.com|Extending permissions on tables to sequences|Jaime Casanova|reviewers=Alvaro Herrera, Abhijit Menon-Sen|status=Waiting for response}}<br />
{{comment|Abhijit Menon-Sen|The patch looks OK (modulo some {{messageLink|20080710031140.GA427@toroid.org|nits}}), but do we want the feature at all?}}<br />
{{comment|Jaime Casanova|updated patch {{messageLink|3073cc9b0807110957w71869487p17fb58cb98abc520@mail.gmail.com|here}}}}<br />
{{comment|tgl|here are {{messageLink|24460.1215895820@sss.pgh.pa.us|some things to think about}} before we can accept the patch}}<br />
<br />
{{patch|162867790806030403r221a6ae3s657f78ad2da9237f@mail.gmail.com|Table function support|Pavel Stěhule|reviewers=Marko Kreen, Tom Lane}}<br />
{{review|e51f66da0807090405gd5ad4c3h892986181cf09d7a@mail.gmail.com|Marko Kreen|Minor issues}}<br />
{{comment|Pavel Stehule|update patch {{messageLink|162867790807100638n47c00eb4w304473a247a20aa7@mail.gmail.com|here}}}}<br />
<br />
{{patch|483FD205.4090904@sigaev.ru|GIN fast insert()|Teodor Sigaev, Oleg Bartunov|reviewers=Thomas Lee, Bruce Momjian}} <br />
{{comment|teodor|updated patch {{messageLink|4849418C.6080909@sigaev.ru|here}}}}<br />
{{comment|thomas.lee|will likely need somebody else to assist with this particular review as I'm relatively new to postgres}}<br />
{{comment|teodor|synced with CVS patch {{messageLink|486BC501.6060605@sigaev.ru|here}}}}<br />
{{comment|teodor|synced with CVS with already committed multicolumn GIN patch {{messageLink|487A6E0C.3090600@sigaev.ru|here}}}}<br />
<br />
{{patch|2e78013d0806092232h6ca15ffejcbcd24e88401308f@mail.gmail.com|VACUUM Improvements - Avoiding second heap scan|Pavan Deolasee|status=WIP|reviewers=Alvaro Herrera}}<br />
{{comment|tgl|reviews {{messageLink|1214898094.3845.537.camel@ebony.site|here}} and {{messageLink|21751.1215883933@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|36152.64.119.130.186.1213364119.squirrel@mail.mohawksoft.com|SSL configure patch|Mark Woodward|reviewers=Abhijit Menon-Sen|status=Waiting for response}}<br />
{{comment|ams|review {{messageLink|20080708025729.GA18515@toroid.org|here}} with some issues, updated patch {{messageLink|20080708030552.GA18801@toroid.org|here}}}}<br />
<br />
{{patch|485A3F20.1080907@cybertec.at|posix fadvises|Zoltan Boszormenyi, Greg Stark|reviewers=Greg Smith, Abhijit Menon-Sen|status=Waiting for response}}<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei|reviewers=Peter Eisentraut, Abhijit Menon-Sen}}<br />
<br />
{{patch|1210171029.4268.115.camel@ebony.site|pg_dump additional options for performance|Simon Riggs|reviewers=Stephen Frost}}<br />
<br />
{{patch|20080626214839.xbfsvm8740gsswos@webmail.cecs.pdx.edu|EXPLAIN in XML format|Tom Raney, Germán Poó Caamaño}}<br />
{{comment|David Fetter|updated patch {{messageLink|20080701214825.m2eczeym8404ss4g@webmail.cecs.pdx.edu|here}}}}<br />
{{comment|Simon Riggs|comments posted {{messageLink|1215188448.4051.225.camel@ebony.site|on-list}} - IMHO not ready for commit}}<br />
<br />
{{patch|4013F1AE-FE1B-427B-8C23-1A5681DA297E@kineticode.com|CITEXT: A case-insensitive TEXT type|David E. Wheeler|reviewers=Zdeněk Kotala|status=Waiting on author}}<br />
{{comment|David Wheeler|v2 patch {{messageLink|ACEC459B-CB5B-4B71-87FA-55E6A649C17C@kineticode.com|here}}}}<br />
{{comment|David Wheeler|v3 patch {{messageLink|890EA230-DA04-4D65-996F-5E7107690BE8@kineticode.com|here}}}}<br />
{{comment|David Wheeler|v4 patch {{messageLink|34AAF859-C4A5-4E6A-A20C-E836631EE32F@kineticode.com|here}}}}<br />
<br />
{{patch|48651722.8020600@enterprisedb.com|Relation forks|Heikki Linnakangas|status=Waiting on author|reviewers=Tom Lane}}<br />
{{comment|tgl|looks committable after addressing these {{messageLink|22640.1215887277@sss.pgh.pa.us|minor nits}}}}<br />
<br />
{{patch|48651722.8020600@enterprisedb.com|FSM rewrite|Heikki Linnakangas}}<br />
{{comment|Simon Riggs|comments posted on-list with further ideas}}<br />
<br />
{{patch|87wsn82lda.fsf@oxford.xeocode.com|SIGINFO to EXPLAIN queries in progress|status=Proof of Concept|Greg Stark}}<br />
{{comment|tgl|seems to me this was already adequately reviewed (and mostly rejected) in the original thread}}<br />
<br />
{{patch|1214865781.3845.525.camel@ebony.site|Hint Bits and Write I/O|Simon Riggs|reviewers=Pavan Deolasee}}<br />
<br />
{{patch|1214901548.3845.544.camel@ebony.site|pg_standby minor changes for Windows|Simon Riggs|reviewers=Martin Zaun}}<br />
<br />
{{patch|20080623150535.946E.52131E4D@oss.ntt.co.jp|executor_hook|Takahiro Itagaki|status=Ready to Commit|reviewers=Simon Riggs}}<br />
{{comment|tgl|don't like exposing ExecutePlan, why not hook at ExecutorRun?}}<br />
{{comment|itagaki|updated patch {{messageLink|20080716104154.7860.52131E4D@oss.ntt.co.jp|here}}}}<br />
<br />
{{patch|de5165440807010758h147d5fw1fc969bc66dcb300@mail.gmail.com|Collation at database level|status=WIP |Radek Strnad }}<br />
<br />
{{patch|48325386.2010506@esilo.com|libpq object hooks|Merlin Moncure, Andrew Chernow|status=WIP}}<br />
<br />
{{patch|BAY102-W42AF4FE40B20BE3C18EE73F2980@phx.gbl|Auto-Explain|Dean Rasheed|reviewers=Simon Riggs}}<br />
{{comment|Simon Riggs|Code location needs review; change proposal made to -hackers}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Committed patches}}<br />
<br />
{{patch|20080512215757.GB22159@fetter.org|psql: \timing as a boolean arg|David Fetter|status=Committed 2008-06-11|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|4851FC54.2020708@timbira.com|small typo in DTrace docs|Euler Taveira de Oliveira|status=Committed 2008-06-18|reviewers=Neil Conway}}<br />
{{comment|alvherre|Note another typo "definitons" in patch}}<br />
<br />
{{patch|486101C0.9090006@vector-seven.com|GUC variable to replace PGBE_ACTIVITY_SIZE|Thomas Lee|status=Committed 2008-06-30|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|482CBDB0.7020901@students.mimuw.edu.pl|extend VacAttrStats to allowstavalues of different types|Jan Urbański|status=Committed 2008-07-01|reviewers=Heikki Linnakangas}}<br />
{{comment|Jan Urbański|updated patch {{messageLink|484418B8.6060004@students.mimuw.edu.pl|here}}}}<br />
<br />
{{patch|20080612091033.40e02ebd@greg-laptop|Better formatting of functions in pg_dump|Greg Sabino Mullane|status=Committed 2008-07-01|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|4831BD6B.5070109@lelarge.info|multi-version support for psql \d commands|Guillaume Lelarge|status=Committed 2008-07-02|reviewers=Tom Lane}}<br />
{{comment|gleu|updated patch {{messageLink|48333337.4040105@lelarge.info|here}}}}<br />
<br />
{{patch|937d27e10805021354s70b24c0l29f7f18dc0ad0ec9@mail.gmail.com|pg_get_keywords()|Dave Page|status=Committed 2008-07-03|reviewers=Nikhil Sontakke, Tom Lane}} <br />
{{comment|dpage|updated patch {{messageLink|937d27e10805031344n440e5ea5mbff6f5cda9d548f9@mail.gmail.com|here}}}}<br />
{{comment|nikhils|review complete from my side. Updated patch along with comments posted back {{messageLink|d3c4af540807022352w1876fe8fu60c1533396f9eb2c@mail.gmail.com|here}}}}<br />
<br />
{{patch|1215258625.4051.281.camel@ebony.site|pg_standby keepfiles calc bug|Simon Riggs|status=Committed 2008-07-08|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|79636C5E324155408C7FA171@imhotep.credativ.de|Adding variables for segment_size, wal_segment_size and block sizes|Bernd Helmle|reviewers=Abhijit Menon-Sen, Tom Lane|status=Committed 2008-07-10}}<br />
<br />
{{patch|483FD205.4090904@sigaev.ru|multicolumn GIN|Teodor Sigaev, Oleg Bartunov|status=Committed 2008-07-11|reviewers=Neil Conway, Tom Lane}} <br />
{{comment|teodor|synced with CVS patch {{messageLink|486BC501.6060605@sigaev.ru|here}}. I'd like to commit this patch before GIN fast insert one}}<br />
<br />
{{patch|48529B83.9010907@sun.com|page macros cleanup|Zdeněk Kotala|status=Committed 2008-07-13|reviewers=Pavan Deolasee, Heikki Linnakangas}}<br />
{{comment|Zdeněk|updated patch {{messageLink|486E138F.4060900@sun.com|here}} - ver 04}}<br />
<br />
{{patch|48649261.5040703@students.mimuw.edu.pl|text search ANALYZE enhancements|Jan Urbański| status=Committed 2008-07-13|reviewers=Tom Lane}}<br />
{{comment|tgl|review {{messageLink|6233.1215113144@sss.pgh.pa.us|here}} --- data structure could be improved and simplified}}<br />
{{comment|tgl|updated version {{messageLink|48791B16.3040207@students.mimuw.edu.pl|here}}}}<br />
<br />
{{patch|162867790806052206l7f6aae61ha29f6720c66caa6@mail.gmail.com|array_fill function|Pavel Stěhule|status=Committed 2008-07-15|reviewers=Thomas Lee, Bruce Momjian}}<br />
<br />
{{patch|162867790806230613w5719d25ejd2a03fac84792d18@mail.gmail.com|Custom variadic functions|Pavel Stěhule|status=Committed 2008-07-15|reviewers=Jeff Davis, Tom Lane}}<br />
{{comment|pavel|updated patch {{messageLink|162867790806240810jc61fd56le8563fe4f7d9a265@mail.gmail.com|here}}}}<br />
{{review|1215929576.11352.62.camel@jdavis|Jeff Davis|Minor issues}}<br />
{{comment|tgl|comments posted {{messageLink|10119.1215966728@sss.pgh.pa.us|here}}}}<br />
{{comment|pavel|updated patch {{messageLink|162867790807140617s105a0a5ew61100897db52d23b@mail.gmail.com|here}}}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Returned with Feedback}}<br />
<br />
{{patch|1214858056.3845.514.camel@ebony.site|Stats Hooks|Simon Riggs|status=Returned for rework|reviewers=Tom Lane}}<br />
{{comment|Josh Berkus|[http://archives.postgresql.org/pgsql-hackers/2008-06/msg00975.php discussion of this patch is here]}}<br />
{{comment|tgl|review {{messageLink|12400.1215716369@sss.pgh.pa.us|here}} --- won't work as submitted}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Round Robin Reviewers ==<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="width: 60%; border-collapse: collapse; border: 1px solid #ccc; font-size: 90%;"<br />
|- style="background: #eee;"<br />
! width="30%" | Name<br />
!Status<br />
!Patch Count<br />
|-<br />
|Neil Conway || Available || 0<br />
|-<br />
|Jeff Davis || Available || 1<br />
|-<br />
|Pavan Deolasee || Available || 2<br />
|-<br />
|Andrew Dunstan || Vacation || 0<br />
|-<br />
|Stephen Frost || Available || 2<br />
|-<br />
|Álvaro Herrera || Available || 2<br />
|-<br />
|Zdeněk Kotala || Vacation || 2<br />
|-<br />
|Thomas Lee || Available || 2<br />
|-<br />
|Abhijit Menon-Sen || Available || 3<br />
|-<br />
|Bruce Momjian || Available || 2<br />
|-<br />
|Nikhil Sontakke || Available || 1<br />
|-<br />
|Greg Stark || Available || 1<br />
|-<br />
|Martin Zaun || Available || 1<br />
|}</div>Theoryhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-07&diff=1685CommitFest 2008-072008-07-08T01:06:10Z<p>Theory: Added link to v3 CITEXT patch.</p>
<hr />
<div>= CommitFest =<br />
<br />
This is the page for CommitFest starting July 2008<br />
<br />
{{CommitFestCurrent}}<br />
<br />
{{CommitFestSection|Pending patches}}<br />
<br />
{{patch|20080511113047.GV5673@sonic.net|pg_dump lock timeout|Dave Gould|status=WIP|reviewers=David Fetter, Stephen Frost}}<br />
{{review|20080703013346.GP31154@tamriel.snowman.net|Stephen Frost|Couple of minor changes requested, otherwise good}}<br />
{{comment|Stephen Frost|Dave Gould will make the changes agreed on and provide an update.}}<br />
<br />
{{patch|20080518.205129.86993930.t-ishii@sraoss.co.jp|WITH RECURSIVE|Yoshiyuki Asaba|status=Pending Review|reviewers=David Fetter}}<br />
{{review|20080518.205129.86993930.t-ishii@sraoss.co.jp|David Fetter|Updated with fixes from Yoshiyuki Asaba and Michael Meskes}}<br />
{{comment|alvherre|There's a long TODO list {{messageLink|20080527.101013.85412760.t-ishii@sraoss.co.jp|here}}}}<br />
{{comment|David Fetter|update patch {{messageLink|20080702231101.GH19610@fetter.org|here}}}}<br />
<br />
{{patch|482F955D.1050600@sun.com|DTrace probe additions|Robert Lor|reviewers=Zdeněk Kotala}}<br />
{{comment|Theo Schlossnagle|another {{messageLink|BB9C10CC-EF5F-442F-949F-2D1E9C6F7A85@omniti.com|DTrace probe patch}}}}<br />
{{comment|Zdeněk Kotala|Robert Treat sent {{messageLink|200807022300.19538.xzilla@users.sourceforge.net|merge of DTrace probe patches}}}}<br />
<br />
{{patch|e51f66da0805141329p3604a350mef9e997a4379b62f@mail.gmail.com|PL/Proxy|Marko Kreen|reviewers=Greg Stark}}<br />
{{comment|David Fetter|Next revision of the {{messageLink|e51f66da0806280636p1c76a953p37eeb72ecfb0b3a8@mail.gmail.com|patch here.}}}}<br />
<br />
{{patch|c2d9e70e0805232156p20dbe2b9j2a88d35f951d625e@mail.gmail.com|Extending permissions on tables to sequences|Jaime Casanova|reviewers=Alvaro Herrera}}<br />
<br />
{{patch|162867790806030403r221a6ae3s657f78ad2da9237f@mail.gmail.com|Table function support|Pavel Stěhule|reviewers=Marko Kreen}}<br />
<br />
{{patch|162867790806052206l7f6aae61ha29f6720c66caa6@mail.gmail.com|array_fill function|Pavel Stěhule|reviewers=Thomas Lee, Bruce Momjian}}<br />
<br />
{{patch|483FD205.4090904@sigaev.ru|GIN fast insert()|Teodor Sigaev, Oleg Bartunov|reviewers=Thomas Lee, Bruce Momjian}} <br />
{{comment|teodor|updated patch {{messageLink|4849418C.6080909@sigaev.ru|here}}}}<br />
{{comment|thomas.lee|will likely need somebody else to assist with this particular review as I'm relatively new to postgres}}<br />
{{comment|teodor|synced with CVS patch {{messageLink|486BC501.6060605@sigaev.ru|here}}}}<br />
<br />
{{patch|483FD205.4090904@sigaev.ru|multicolumn GIN|Teodor Sigaev, Oleg Bartunov|reviewers=Neil Conway}} <br />
{{comment|teodor|synced with CVS patch {{messageLink|486BC501.6060605@sigaev.ru|here}}. I'd like to commit this patch before GIN fast insert one}}<br />
<br />
{{patch|2e78013d0806092232h6ca15ffejcbcd24e88401308f@mail.gmail.com|VACUUM Improvements - Avoiding second heap scan|Pavan Deolasee|status=WIP}}<br />
<br />
{{patch|36152.64.119.130.186.1213364119.squirrel@mail.mohawksoft.com|SSL configure patch|Mark Woodward|reviewers=Abhijit Menon-Sen}}<br />
<br />
{{patch|48529B83.9010907@sun.com|page macros cleanup|Zdeněk Kotala|reviewers=Pavan Deolasee}}<br />
{{comment|Zdeněk|updated patch {{messageLink|486E138F.4060900@sun.com|here}} - ver 04}}<br />
<br />
{{patch|485A3F20.1080907@cybertec.at|posix fadvises|Zoltan Boszormenyi, Greg Stark|reviewers=Greg Smith}}<br />
<br />
{{patch|162867790806230613w5719d25ejd2a03fac84792d18@mail.gmail.com|Custom variadic functions|Pavel Stěhule}}<br />
{{comment|pavel|updated patch {{messageLink|162867790806240810jc61fd56le8563fe4f7d9a265@mail.gmail.com|here}}}}<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei}}<br />
<br />
{{patch|1210171029.4268.115.camel@ebony.site|pg_dump additional options for performance|Simon Riggs|reviewers=Stephen Frost}}<br />
<br />
{{patch|20080626214839.xbfsvm8740gsswos@webmail.cecs.pdx.edu|EXPLAIN in XML format|Tom Raney, Germán Poó Caamaño}}<br />
{{comment|David Fetter|updated patch {{messageLink|20080701214825.m2eczeym8404ss4g@webmail.cecs.pdx.edu|here}}}}<br />
{{comment|Simon Riggs|comments posted on-list - IMHO not ready for commit}}<br />
<br />
{{patch|4013F1AE-FE1B-427B-8C23-1A5681DA297E@kineticode.com|CITEXT: A case-insensitive TEXT type|David E. Wheeler|reviewers=Zdeněk Kotala}}<br />
{{comment|David Wheeler|v2 patch {{messageLink|ACEC459B-CB5B-4B71-87FA-55E6A649C17C@kineticode.com|here}}}}<br />
{{comment|David Wheeler|v3 patch {{messageLink|890EA230-DA04-4D65-996F-5E7107690BE8@kineticode.com|here}}}}<br />
<br />
{{patch|48651722.8020600@enterprisedb.com|Relation forks|Heikki Linnakangas}}<br />
<br />
{{patch|48651722.8020600@enterprisedb.com|FSM rewrite|Heikki Linnakangas}}<br />
{{comment|Simon Riggs|comments posted on-list with further ideas}}<br />
<br />
{{patch|87wsn82lda.fsf@oxford.xeocode.com|SIGINFO to EXPLAIN queries in progress|status=Proof of Concept|Greg Stark}}<br />
<br />
{{patch|1214858056.3845.514.camel@ebony.site|Stats Hooks|Simon Riggs}}<br />
<br />
{{patch|1214865781.3845.525.camel@ebony.site|Hint Bits and Write I/O|Simon Riggs|reviewers=Pavan Deolasee}}<br />
<br />
{{patch|1214901548.3845.544.camel@ebony.site|pg_standby minor changes for Windows|Simon Riggs|reviewers=Martin Zaun}}<br />
<br />
{{patch|20080623150535.946E.52131E4D@oss.ntt.co.jp|executor_hook|Takahiro Itagaki|reviewers=Simon Riggs}}<br />
{{comment|Simon Riggs|executor_hook.patch looks good. OK to commit}}<br />
<br />
{{patch|de5165440807010758h147d5fw1fc969bc66dcb300@mail.gmail.com|Collation at database level|status=WIP |Radek Strnad }}<br />
<br />
{{patch|48325386.2010506@esilo.com|libpq object hooks|Merlin Moncure, Andrew Chernow|status=WIP}}<br />
<br />
{{patch|BAY102-W42AF4FE40B20BE3C18EE73F2980@phx.gbl|Auto-Explain|Dean Rasheed|reviewers=Simon Riggs}}<br />
<br />
{{patch|1215258625.4051.281.camel@ebony.site|pg_standby keepfiles calc bug|Simon Riggs}}<br />
<br />
{{patch|79636C5E324155408C7FA171@imhotep.credativ.de|Adding variables for segment_size, wal_segment_size and block sizes|Bernd Helmle}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Committed patches}}<br />
<br />
{{patch|20080512215757.GB22159@fetter.org|psql: \timing as a boolean arg|David Fetter|status=Committed 2008-06-11|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|4851FC54.2020708@timbira.com|small typo in DTrace docs|Euler Taveira de Oliveira|status=Committed 2008-06-18|reviewers=Neil Conway}}<br />
{{comment|alvherre|Note another typo "definitons" in patch}}<br />
<br />
{{patch|486101C0.9090006@vector-seven.com|GUC variable to replace PGBE_ACTIVITY_SIZE|Thomas Lee|status=Committed 2008-06-30|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|482CBDB0.7020901@students.mimuw.edu.pl|extend VacAttrStats to allowstavalues of different types|Jan Urbański|status=Committed 2008-07-01|reviewers=Heikki Linnakangas}}<br />
{{comment|Jan Urbański|updated patch {{messageLink|484418B8.6060004@students.mimuw.edu.pl|here}}}}<br />
<br />
{{patch|20080612091033.40e02ebd@greg-laptop|Better formatting of functions in pg_dump|Greg Sabino Mullane|status=Committed 2008-07-01|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|4831BD6B.5070109@lelarge.info|multi-version support for psql \d commands|Guillaume Lelarge|status=Committed 2008-07-02|reviewers=Tom Lane}}<br />
{{comment|gleu|updated patch {{messageLink|48333337.4040105@lelarge.info|here}}}}<br />
<br />
{{patch|937d27e10805021354s70b24c0l29f7f18dc0ad0ec9@mail.gmail.com|pg_get_keywords()|Dave Page|status=Committed 2008-07-03|reviewers=Nikhil Sontakke, Tom Lane}} <br />
{{comment|dpage|updated patch {{messageLink|937d27e10805031344n440e5ea5mbff6f5cda9d548f9@mail.gmail.com|here}}}}<br />
{{comment|nikhils|review complete from my side. Updated patch along with comments posted back {{messageLink|d3c4af540807022352w1876fe8fu60c1533396f9eb2c@mail.gmail.com|here}}}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Returned with Feedback}}<br />
<br />
{{patch|48649261.5040703@students.mimuw.edu.pl|text search selectivity and dllist enhancements|Jan Urbański|status=Returned for rework|reviewers=Tom Lane}}<br />
{{comment|tgl|review {{messageLink|6233.1215113144@sss.pgh.pa.us|here}} --- data structure could be improved and simplified}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Round Robin Reviewers ==<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="width: 60%; border-collapse: collapse; border: 1px solid #ccc; font-size: 90%;"<br />
|- style="background: #eee;"<br />
! width="30%" | Name<br />
!Status<br />
!Patch Count<br />
|-<br />
|Neil Conway || Available || 1<br />
|-<br />
|Pavan Deolasee || Available || 2<br />
|-<br />
|Andrew Dunstan || Vacation || 0<br />
|-<br />
|Stephen Frost || Available || 2<br />
|-<br />
|Álvaro Herrera || Available || 1<br />
|-<br />
|Zdeněk Kotala || Available || 1<br />
|-<br />
|Thomas Lee || Available || 2<br />
|-<br />
|Abhijit Menon-Sen || Available || 1<br />
|-<br />
|Bruce Momjian || Available || 2<br />
|-<br />
|Nikhil Sontakke || Available || 1<br />
|-<br />
|Greg Stark || Available || 1<br />
|-<br />
|Martin Zaun || Available || 1<br />
|}</div>Theoryhttps://wiki.postgresql.org/index.php?title=Oscon_2008_signup&diff=1672Oscon 2008 signup2008-07-07T17:27:59Z<p>Theory: /* 12:20 - 13:40 LUNCH */</p>
<hr />
<div>*To keep the cohesive "Army of Smurfs" appearance, JD would like everyone to wear a PostgreSQL t-shirt while staffing the booth. If you do not already have one, one will be provided for you.<br />
<br />
== Wed (10:00-16:30) (10am-4:30pm) ==<br />
<br />
=== 10:45 - 11:30 ===<br />
* Daniel Johnson<br />
<br />
=== 11:35 - 12:15 ===<br />
<br />
=== 12:20 - 13:40 LUNCH ===<br />
<br />
* David Wheeler<br />
<br />
=== 13:45 - 14:30 ===<br />
<br />
=== 14:35 - 15:15 ===<br />
* Selena & I are OUT<br />
<br />
=== 15:20 - 16:25 ===<br />
<br />
=== 18:00 - 19:30 RECEPTION ===<br />
* Not sure if we need somebody at the booth or not, but sign up if you feel like it.<br />
<br />
== Thurs 10:00 - 17:00 (10am-5pm) ==<br />
<br />
=== 10:45 - 11:30 ===<br />
* YOUR NAME HERE!<br />
<br />
=== 11:35 - 12:15 ===<br />
<br />
=== 12:20 - 13:40 LUNCH ===<br />
<br />
=== 13:45 - 14:30 ===<br />
<br />
=== 14:35 - 15:15 ===<br />
<br />
=== 15:20 - 16:25 ===<br />
<br />
=== 16:30 - 17:00 ===<br />
<br />
<br />
----<br />
<br />
Thanks for participating!</div>Theoryhttps://wiki.postgresql.org/index.php?title=Oscon_2008_signup&diff=1671Oscon 2008 signup2008-07-07T17:27:14Z<p>Theory: /* 12:20 - 13:40 LUNCH */</p>
<hr />
<div>*To keep the cohesive "Army of Smurfs" appearance, JD would like everyone to wear a PostgreSQL t-shirt while staffing the booth. If you do not already have one, one will be provided for you.<br />
<br />
== Wed (10:00-16:30) (10am-4:30pm) ==<br />
<br />
=== 10:45 - 11:30 ===<br />
* Daniel Johnson<br />
<br />
=== 11:35 - 12:15 ===<br />
<br />
=== 12:20 - 13:40 LUNCH ===<br />
<br />
David Wheeeler<br />
<br />
=== 13:45 - 14:30 ===<br />
<br />
=== 14:35 - 15:15 ===<br />
* Selena & I are OUT<br />
<br />
=== 15:20 - 16:25 ===<br />
<br />
=== 18:00 - 19:30 RECEPTION ===<br />
* Not sure if we need somebody at the booth or not, but sign up if you feel like it.<br />
<br />
== Thurs 10:00 - 17:00 (10am-5pm) ==<br />
<br />
=== 10:45 - 11:30 ===<br />
* YOUR NAME HERE!<br />
<br />
=== 11:35 - 12:15 ===<br />
<br />
=== 12:20 - 13:40 LUNCH ===<br />
<br />
=== 13:45 - 14:30 ===<br />
<br />
=== 14:35 - 15:15 ===<br />
<br />
=== 15:20 - 16:25 ===<br />
<br />
=== 16:30 - 17:00 ===<br />
<br />
<br />
----<br />
<br />
Thanks for participating!</div>Theoryhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-07&diff=1657CommitFest 2008-072008-07-06T06:34:26Z<p>Theory: Added link to updated CITEXT patch.</p>
<hr />
<div>= CommitFest =<br />
<br />
This is the page for CommitFest starting July 2008<br />
<br />
{{CommitFestCurrent}}<br />
<br />
{{CommitFestSection|Pending patches}}<br />
<br />
{{patch|20080511113047.GV5673@sonic.net|pg_dump lock timeout|Dave Gould|status=WIP|reviewers=David Fetter}}<br />
<br />
{{patch|20080518.205129.86993930.t-ishii@sraoss.co.jp|WITH RECURSIVE|Yoshiyuki Asaba|status=WIP|reviewers=David Fetter}}<br />
{{review|20080518.205129.86993930.t-ishii@sraoss.co.jp|David Fetter|Updated with fixes from Yoshiyuki Asaba and Michael Meskes}}<br />
{{comment|alvherre|There's a long TODO list {{messageLink|20080527.101013.85412760.t-ishii@sraoss.co.jp|here}}}}<br />
{{comment|David Fetter|update patch {{messageLink|20080702231101.GH19610@fetter.org|here}}}}<br />
<br />
{{patch|482F955D.1050600@sun.com|DTrace probe additions|Robert Lor|reviewers=Zdeněk Kotala}}<br />
{{comment|Theo Schlossnagle|another {{messageLink|BB9C10CC-EF5F-442F-949F-2D1E9C6F7A85@omniti.com|DTrace probe patch}}}}<br />
{{comment|Zdeněk Kotala|Robert Treat sent {{messageLink|200807022300.19538.xzilla@users.sourceforge.net|merge of DTrace probe patches}}}}<br />
<br />
{{patch|e51f66da0805141329p3604a350mef9e997a4379b62f@mail.gmail.com|PL/Proxy|Marko Kreen}}<br />
{{comment|David Fetter|Next revision of the {{messageLink|e51f66da0806280636p1c76a953p37eeb72ecfb0b3a8@mail.gmail.com|patch here.}}}}<br />
<br />
{{patch|c2d9e70e0805232156p20dbe2b9j2a88d35f951d625e@mail.gmail.com|Extending permissions on tables to sequences|Jaime Casanova|}}<br />
<br />
{{patch|162867790806030403r221a6ae3s657f78ad2da9237f@mail.gmail.com|Table function support|Pavel Stěhule|reviewers=Marko Kreen}}<br />
<br />
{{patch|162867790806052206l7f6aae61ha29f6720c66caa6@mail.gmail.com|array_fill function|Pavel Stěhule|reviewers=Thomas Lee}}<br />
<br />
{{patch|483FD205.4090904@sigaev.ru|GIN fast insert()|Teodor Sigaev, Oleg Bartunov|reviewers=Thomas Lee}} <br />
{{comment|teodor|updated patch {{messageLink|4849418C.6080909@sigaev.ru|here}}}}<br />
{{comment|thomas.lee|will likely need somebody else to assist with this particular review as I'm relatively new to postgres}}<br />
{{comment|teodor|synced with CVS patch {{messageLink|486BC501.6060605@sigaev.ru|here}}}}<br />
<br />
{{patch|483FD205.4090904@sigaev.ru|multicolumn GIN|Teodor Sigaev, Oleg Bartunov}} <br />
{{comment|teodor|synced with CVS patch {{messageLink|486BC501.6060605@sigaev.ru|here}}. I'd like to commit this patch before GIN fast insert one}}<br />
<br />
{{patch|2e78013d0806092232h6ca15ffejcbcd24e88401308f@mail.gmail.com|VACUUM Improvements - Avoiding second heap scan|Pavan Deolasee|status=WIP}}<br />
<br />
{{patch|36152.64.119.130.186.1213364119.squirrel@mail.mohawksoft.com|SSL configure patch|Mark Woodward}}<br />
<br />
{{patch|48529B83.9010907@sun.com|page macros cleanup|Zdeněk Kotala|reviewers=Pavan Deolasee}}<br />
{{comment|Zdeněk|updated patch {{messageLink|486E138F.4060900@sun.com|here}} - ver 04}}<br />
<br />
{{patch|485A3F20.1080907@cybertec.at|posix fadvises|Zoltan Boszormenyi, Greg Stark|reviewers=Greg Smith}}<br />
<br />
{{patch|162867790806230613w5719d25ejd2a03fac84792d18@mail.gmail.com|Custom variadic functions|Pavel Stěhule}}<br />
{{comment|pavel|updated patch {{messageLink|162867790806240810jc61fd56le8563fe4f7d9a265@mail.gmail.com|here}}}}<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei}}<br />
<br />
{{patch|1210171029.4268.115.camel@ebony.site|pg_dump additional options for performance|Simon Riggs}}<br />
<br />
{{patch|20080626214839.xbfsvm8740gsswos@webmail.cecs.pdx.edu|EXPLAIN in XML format|Tom Raney, Germán Poó Caamaño}}<br />
{{comment|David Fetter|updated patch {{messageLink|20080701214825.m2eczeym8404ss4g@webmail.cecs.pdx.edu|here}}}}<br />
{{comment|Simon Riggs|comments posted on-list - IMHO not ready for commit}}<br />
<br />
{{patch|4013F1AE-FE1B-427B-8C23-1A5681DA297E@kineticode.com|CITEXT: A case-insensitive TEXT type|David E. Wheeler|reviewers=Zdeněk Kotala|status=Waiting on new revision}}<br />
{{comment|David Wheeler|updated patch {{messageLink|ACEC459B-CB5B-4B71-87FA-55E6A649C17C@kineticode.com|here}}}}<br />
<br />
{{patch|48651722.8020600@enterprisedb.com|Relation forks|Heikki Linnakangas}}<br />
<br />
{{patch|48651722.8020600@enterprisedb.com|FSM rewrite|Heikki Linnakangas}}<br />
{{comment|Simon Riggs|comments posted on-list with further ideas}}<br />
<br />
{{patch|87wsn82lda.fsf@oxford.xeocode.com|SIGINFO to EXPLAIN queries in progress|status=Proof of Concept|Greg Stark}}<br />
<br />
{{patch|1214858056.3845.514.camel@ebony.site|Stats Hooks|Simon Riggs}}<br />
<br />
{{patch|1214865781.3845.525.camel@ebony.site|Hint Bits and Write I/O|Simon Riggs|reviewers=Pavan Deolasee}}<br />
<br />
{{patch|1214901548.3845.544.camel@ebony.site|pg_standby minor changes for Windows|Simon Riggs|reviewers=Martin Zaun}}<br />
<br />
{{patch|20080623150535.946E.52131E4D@oss.ntt.co.jp|executor_hook|Takahiro Itagaki|reviewers=Simon Riggs}}<br />
{{comment|Simon Riggs|executor_hook.patch looks good. OK to commit}}<br />
<br />
{{patch|de5165440807010758h147d5fw1fc969bc66dcb300@mail.gmail.com|Collation at database level|status=WIP |Radek Strnad }}<br />
<br />
{{patch|48325386.2010506@esilo.com|libpq object hooks|Merlin Moncure, Andrew Chernow|status=WIP}}<br />
<br />
{{patch|BAY102-W42AF4FE40B20BE3C18EE73F2980@phx.gbl|Auto-Explain|Dean Rasheed|reviewers=Simon Riggs}}<br />
<br />
{{patch||pg_standby keepfiles calc bug|Simon Riggs}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Committed patches}}<br />
<br />
{{patch|20080512215757.GB22159@fetter.org|psql: \timing as a boolean arg|David Fetter|status=Committed 2008-06-11|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|4851FC54.2020708@timbira.com|small typo in DTrace docs|Euler Taveira de Oliveira|status=Committed 2008-06-18|reviewers=Neil Conway}}<br />
{{comment|alvherre|Note another typo "definitons" in patch}}<br />
<br />
{{patch|486101C0.9090006@vector-seven.com|GUC variable to replace PGBE_ACTIVITY_SIZE|Thomas Lee|status=Committed 2008-06-30|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|482CBDB0.7020901@students.mimuw.edu.pl|extend VacAttrStats to allowstavalues of different types|Jan Urbański|status=Committed 2008-07-01|reviewers=Heikki Linnakangas}}<br />
{{comment|Jan Urbański|updated patch {{messageLink|484418B8.6060004@students.mimuw.edu.pl|here}}}}<br />
<br />
{{patch|20080612091033.40e02ebd@greg-laptop|Better formatting of functions in pg_dump|Greg Sabino Mullane|status=Committed 2008-07-01|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|4831BD6B.5070109@lelarge.info|multi-version support for psql \d commands|Guillaume Lelarge|status=Committed 2008-07-02|reviewers=Tom Lane}}<br />
{{comment|gleu|updated patch {{messageLink|48333337.4040105@lelarge.info|here}}}}<br />
<br />
{{patch|937d27e10805021354s70b24c0l29f7f18dc0ad0ec9@mail.gmail.com|pg_get_keywords()|Dave Page|status=Committed 2008-07-03|reviewers=Nikhil Sontakke, Tom Lane}} <br />
{{comment|dpage|updated patch {{messageLink|937d27e10805031344n440e5ea5mbff6f5cda9d548f9@mail.gmail.com|here}}}}<br />
{{comment|nikhils|review complete from my side. Updated patch along with comments posted back {{messageLink|d3c4af540807022352w1876fe8fu60c1533396f9eb2c@mail.gmail.com|here}}}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Returned with Feedback}}<br />
<br />
{{patch|48649261.5040703@students.mimuw.edu.pl|text search selectivity and dllist enhancements|Jan Urbański|status=Returned for rework|reviewers=Tom Lane}}<br />
{{comment|tgl|review {{messageLink|6233.1215113144@sss.pgh.pa.us|here}} --- data structure could be improved and simplified}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Round Robin Reviewers ==<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="width: 60%; border-collapse: collapse; border: 1px solid #ccc; font-size: 90%;"<br />
|- style="background: #eee;"<br />
! width="30%" | Name<br />
!Status<br />
!Patch Count<br />
|-<br />
|Greg Stark || Available || 0<br />
|-<br />
|Neil Conway || Available || 0<br />
|-<br />
|Álvaro Herrera || Available || 0<br />
|-<br />
|Martin Zaun || Available || 0<br />
|-<br />
|Thomas Lee || Available || 0<br />
|-<br />
|Nikhil Sontakke || Available || 1<br />
|-<br />
|Abhijit Menon-Sen || Available || 0<br />
|-<br />
|Pavan Deolasee || Available || 2<br />
|-<br />
|Zdeněk Kotala || Available || 1<br />
|-<br />
|Andrew Dunstan || Vacation || 0<br />
|-<br />
|Bruce Momjian || Available || 0<br />
|}</div>Theoryhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-07&diff=1555CommitFest 2008-072008-06-28T01:26:17Z<p>Theory: Added CITEXT patch.</p>
<hr />
<div>= CommitFest =<br />
<br />
{{CommitFestOpen}}<br />
<br />
{{CommitFestSection|Pending patches}}<br />
{{patch|937d27e10805021354s70b24c0l29f7f18dc0ad0ec9@mail.gmail.com|pg_get_keywords()|Dave Page}} <br />
{{comment|dpage|updated patch {{messageLink|937d27e10805031344n440e5ea5mbff6f5cda9d548f9@mail.gmail.com|here}}}}<br />
<br />
{{patch|20080511113047.GV5673@sonic.net|pg_dump lock timeout|daveg}}<br />
<br />
{{patch|482CBDB0.7020901@students.mimuw.edu.pl|extend VacAttrStats to allowstavalues of different types|Jan Urbański}}<br />
{{comment|Jan Urbański|updated patch {{messageLink|484418B8.6060004@students.mimuw.edu.pl|here}}}}<br />
<br />
{{patch|20080518.205129.86993930.t-ishii@sraoss.co.jp|WITH RECURSIVE|Yoshiyuki Asaba|status=WIP|reviewers=David Fetter}}<br />
{{review|20080518.205129.86993930.t-ishii@sraoss.co.jp|David Fetter|Updated with fixes from Yoshiyuki Asaba and Michael Meskes}}<br />
{{comment|alvherre|There's a long TODO list {{messageLink|20080527.101013.85412760.t-ishii@sraoss.co.jp|here}}}}<br />
<br />
{{patch|4831BD6B.5070109@lelarge.info|multi-version support for psql|Guillaume Lelarge}}<br />
{{comment|gleu|updated patch {{messageLink|48333337.4040105@lelarge.info|here}}}}<br />
<br />
{{patch|482F955D.1050600@sun.com|DTrace probe additions|Robert Lor}}<br />
{{comment|Theo Schlossnagle|another {{messageLink|BB9C10CC-EF5F-442F-949F-2D1E9C6F7A85@omniti.com|DTrace probe patch}}}}<br />
<br />
{{patch|e51f66da0805141329p3604a350mef9e997a4379b62f@mail.gmail.com|PL/Proxy|Marko Kreen|status=WIP}}<br />
<br />
{{patch|c2d9e70e0805232156p20dbe2b9j2a88d35f951d625e@mail.gmail.com|Extending permissions on tables to sequences|Jaime Casanova|}}<br />
{{patch|162867790806030403r221a6ae3s657f78ad2da9237f@mail.gmail.com|Table function support|Pavel Stehule}}<br />
{{patch|162867790806052206l7f6aae61ha29f6720c66caa6@mail.gmail.com|array_fill function|Pavel Stehule}}<br />
<br />
{{patch|483FD205.4090904@sigaev.ru|GIN fast insert()|Teodor Sigaev, Oleg Bartunov}} <br />
{{comment|teodor|updated patch {{messageLink|4849418C.6080909@sigaev.ru|here}}}}<br />
<br />
{{patch|483FD205.4090904@sigaev.ru|multicolumn GIN|Teodor Sigaev, Oleg Bartunov}} <br />
<br />
{{patch|2e78013d0806092232h6ca15ffejcbcd24e88401308f@mail.gmail.com|VACUUM Improvements - Avoiding second heap scan|Pavan Deolasee|status=WIP}}<br />
<br />
{{patch|20080612091033.40e02ebd@greg-laptop|Better formatting of functions in pg_dump|Greg Sabino Mullane}}<br />
<br />
{{patch|36152.64.119.130.186.1213364119.squirrel@mail.mohawksoft.com|SSL configure patch|Mark Woodward}}<br />
<br />
{{patch|48529B83.9010907@sun.com|page macros cleanup|Zdenek Kotala}}<br />
<br />
{{patch|4851FC54.2020708@timbira.com|small typo in DTrace docs|Euler Taveira de Oliveira}}<br />
{{comment|alvherre|Note another typo "definitons" in patch}}<br />
<br />
{{patch|485A3F20.1080907@cybertec.at|posix fadvises|Zoltan Boszormenyi, Greg Stark|reviewers=Greg Smith}}<br />
<br />
{{patch|486101C0.9090006@vector-seven.com|GUC variable to replace PGBE_ACTIVITY_SIZE|Thomas Lee}}<br />
<br />
<br />
{{patch|162867790806230613w5719d25ejd2a03fac84792d18@mail.gmail.com|Custom variadic functions|Pavel Stehule}}<br />
{{comment|pavel|updated patch {{messageLink|162867790806240810jc61fd56le8563fe4f7d9a265@mail.gmail.com|here}}}}<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei}}<br />
<br />
{{patch|1210171029.4268.115.camel@ebony.site|pg_dump additional options for performance|Simon Riggs}}<br />
<br />
{{patch|20080626214839.xbfsvm8740gsswos@webmail.cecs.pdx.edu|EXPLAIN in XML format|Tom Raney, Germán Poó Caamaño}}<br />
{{patch|48649261.5040703@students.mimuw.edu.pl|text search selectivity and dllist enhancments|Jan Urbański}}<br />
<br />
{{patch|4013F1AE-FE1B-427B-8C23-1A5681DA297E@kineticode.com|CITEXT: A case-insensitive TEXT type|David E. Wheeler}}<br />
<br />
<!-- Add new patches here --><br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Committed patches}}<br />
<br />
{{patch|20080512215757.GB22159@fetter.org|psql: \timing as a boolean arg|David Fetter|status=Committed 2008-06-11|reviewers=Heikki Linnakangas}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
{{CommitFestSection|Returned with Feedback}}<br />
{{CommitFestEndSection}}<br />
<br />
== Round Robin Reviewers ==<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="width: 60%; border-collapse: collapse; border: 1px solid #ccc; font-size: 90%;"<br />
|- style="background: #eee;"<br />
! width="30%" | Name<br />
!Status<br />
!Patch Count<br />
|-<br />
|Greg Stark || Available || 0<br />
|}</div>Theoryhttps://wiki.postgresql.org/index.php?title=GUCS_Overhaul&diff=1443GUCS Overhaul2008-06-03T04:24:35Z<p>Theory: Typos, grammar, clarity.</p>
<hr />
<div>==Problems==<br />
<br />
Currently, postgresql.conf and our set of GUC configurations suffer from several large problems:<br />
<br />
# Most people have no idea how to set these.<br />
# The current postgresql.conf file is a huge mess of 194 options, the vast majority of which most users will never touch.<br />
# GUCS lists are kept in 3 different places (guc.c, postgresql.conf, and settings.sgml), which are only synched with each other manually.<br />
# We don't seem to be getting any closer to autotuning.<br />
<br />
==Goals==<br />
<br />
* It's vitally important that any overhaul of the GUCS be completed in one version to minimize the pain involved.<br />
* The file format should be standardized in a way that makes it easy to parse and generate.<br />
* The internal data and pg_settings view should contain everything needed to output a new postgresql.conf that's functionally identical to the original<br />
** It may be less practical in cases where there are include files involved.<br />
* By shifting from a model where postgresql.conf is document-formatted and hand-edited to one where it's machine generated, it becomes vastly easier to write simple utilities to manage these settings. Right now, the big "obstacle" to things like SET PERSISTENT is "how to we preserve the hand-edited comments in the file" -- and the answer is we ''don't.''<br />
* The lack of an easy way to manage settings via port access to PostgreSQL is a significant inhibitor to adopting PostgreSQL in environments with large numbers of servers. Making this available would make for easier integration into tools like CPANEL, which in turn would expand PostgreSQL web hosting availability.<br />
<br />
==Gotchas==<br />
* It's impossible to push all the settings into the database itself to eliminate the postgresql.conf altogether, as quite a few of the GUC parameters are needed before one can ever read the database; in particular the ones about file locations and shared memory sizing.<br />
* Tools that operate remotely have to consider that they may make a change that keeps the server from coming back up again. Suppose you change a parameter in a way that breaks the DB (e.g., set shared_buffers to a value larger than your kernel allows) and try to restart. Database doesn't start. If you only have access to the database via port 5432 once it's up, and you can't change the parameter back via editing the file directly, you're hosed.<br />
** To support the hosted server goal, perhaps a backup "known good" backup file can be generated and used if the primary doesn't work.<br />
<br />
==Design Proposal==<br />
It's all a package and should make sense if you consider all of the changes as a whole.<br />
<br />
# Add several pieces of extra information to guc.c in the form of extra "gettext" commands: default value, subcategory, long description, recommendations, enum lists, and when the value can be changed (per session, during server runtime, only by restarting the server). Perhaps also add a link to the full documentation on this option. Another useful addition would be the source for the setting, to distinguish between things sourced from the master file and those coming from include files.<br />
# Add a place to save user comments<br />
# Incorporate this data into pg_settings<br />
# Delete the postgresql.conf.sample file<br />
# Add a script called pg_generate_conf to generate a postgresql.conf based on guc.c and command-line switches (rather than postgresql.conf.sample), and which would be called automatically by initdb.<br />
<br />
===pg_generate_conf===<br />
<br />
pg_generate_conf would take the following switches:<br />
* -b , --basic — short conf file, listing only the 15-18 most commonly changed options<br />
* -a , --advanced — conf file listing all 196+ options<br />
* -t, --terse — conf file lists only category headings and actual settings, no comments<br />
* -n, --normal — conf file has category and subcategory settings, with short, descriptive comments<br />
* -v, --verbose — conf file lists full descriptions and recommendations in comments with each option<br />
* -c "option = value" set specific option to specific value in the file<br />
* -f "filename" — take options and values from file "filename"<br />
<br />
The default would be "-b, -n", with specific settings for shared_buffers and wal_sync_method. The current postgresql.conf is a lot more like a "-a, -v" file.<br />
<br />
This would help us in the following ways:<br />
<br />
* There would now only be 2 places to maintain GUCS lists, the docs and guc.c.<br />
* By having a generated postgresql.conf and an easy way to generate it, writing autoconfiguration scripts (as well as shortcuts like SET PERSISTENT) become vastly easier.<br />
* Most users would deal only with a limited set of 15-20 configuration variables.<br />
<br />
pg_generate_conf should be able to read its own output as an input and generate a new file with the same parameters, but with a different verbosity level.<br />
<br />
===Server side changes===<br />
<br />
There needs to be a way to modify the underlying settings and save that into a new machine-generated postgresql.conf file. Is implementing SET PERSISTENT sufficient for that?<br />
<br />
==Tuning wizard==<br />
<br />
Imagine a GUI or web app that connects to a server on port 5432, finds out some basic information about the server, and then gives something like this:<br />
<br />
<code><pre><br />
Parameter Current Recommended Change?<br />
shared_buffers 32MB 1024MB [X]<br />
effective_cache_size 128MB 3000MB [ ]<br />
work_mem 1MB 16MB [ ]<br />
</pre></code></div>Theory