PostgreSQL wiki - User contributions [en]

User:Mastermind

2025-12-02T20:54:21Z

Mastermind:

I'm Stefan Kaltenbrunner - you can reach me via email to stefan@kaltenbrunner.cc.

Main Page

2025-10-23T14:54:05Z

Mastermind: most of the sysadmin team is not active on IRC any more

__NOTOC__
{{Languages}}
= Welcome to the PostgreSQL Wiki! =

This wiki contains user documentation, how-tos, and tips 'n' tricks related to PostgreSQL. It also serves as a collaboration area for PostgreSQL contributors.

== User Documentation ==
* [[Frequently Asked Questions]]

==== Community Generated Articles, Guides, and Documentation ====
* [[Community Generated Articles, Guides, and Documentation|General articles and guides]]
* [[PostgreSQL Tutorials]]
* [[:Category:Snippets|PostgreSQL Related Code Snippets]]
* [[Detailed installation guides]]
* [[Converting from other Databases to PostgreSQL]]
* [[Comparison with other Database systems]]
* [[Database Administration and Maintenance]]
* [[Development Articles|Development with PostgreSQL]]
* [[Performance Optimization|PostgreSQL Performance Optimization]]
* [[PostgreSQL Related Slides and Presentations]]

==== Documentation on the main site ====
* [http://www.postgresql.org/docs/manuals/ PostgreSQL Manuals]
* [http://www.postgresql.org/docs/books/ PostgreSQL Books]

== Alternate Languages ==

The following pages contain user documentation in languages other than English.

* [[Main Page/de|deutsch]]
* [[Main Page/es|español]]
* [[Main Page/fr|français]]
* [[Main Page/he|עברית]]
* [[Main Page/ja|日本語]]
* [[Main Page/pt|português]]
* [[Main Page/ru|русский]]
* [[Main Page/zh|中文]]
* [[Main Page/zh-hant|中文（繁體]]

== Contributor Information ==
* You can find many PostgreSQL users and developers chatting in [irc://irc.libera.chat/postgresql #postgresql on Libera]. A list of IRC nick names with their respective real world names can be found [[IRC2RWNames | here]].
* [[Events | Upcoming Events]]
* [[Development information]]
* [[Advocacy]]

== User Accounts ==
* All activity on this site should follow the [[Policies|PostgreSQL Project Policies]].
* In order to edit or create documents on the site, you will need a [https://www.postgresql.org/account/login/ PostgreSQL community account]. This is the same account used when submitting news or events on [http://www.postgresql.org www.postgresql.org].
'''NOTE: due to recent spam activity "editor" privileges are granted manually for the time being. If you just created a new community account or if your current account used to have "editor" privileges ask on the [mailto:pgsql-www@postgresql.org PostgreSQL -www Mailinglist] for help. Please include your community account name in those requests.

Infrastructure team

2023-12-15T11:20:48Z

Mastermind:

== Infrastructure Team ==

The Infrastructure team is responsible for running all of the postgresql.org infrastructure. This includes a wide variety of public and non-public services. PostgreSQL website development is discussed on the [http://archives.postgresql.org/pgsql-www/ pgsql-www mailing list]. Source code for the postgresql.org web site is stored in a public GIT repository, and is available on [http://git.postgresql.org/gitweb/?p=pgweb.git;a=summary]

== Infrastructure Team Members ==

The following people are part of the sysadmin team running the postgresql.org infrastructure.

* Stephen Frost
* Magnus Hagander
* Álvaro Herrera
* Stefan Kaltenbrunner
* Dave Page
* Joe Conway
* Christophe Pettus

In case you want to reach out to the Infrastructure team, please contact us at sysadmins@lists.postgresql.org

[[Category:Community]]

Infrastructure team

2023-12-15T11:19:48Z

Mastermind: add email for sysadmins@

== Infrastructure Team ==

The Infrastructure team is responsible for running all of the postgresql.org infrastructure. This includes a wide variety of public and non-public services. PostgreSQL website development is discussed on the [http://archives.postgresql.org/pgsql-www/ pgsql-www mailing list]. Source code for the postgresql.org web site is stored in a public GIT repository, and is available on [http://git.postgresql.org/gitweb/?p=pgweb.git;a=summary]

== Infrastructure Team Members ==

The following people are part of the sysadmin team running the postgresql.org infrastructure.

* Stephen Frost
* Magnus Hagander
* Álvaro Herrera
* Stefan Kaltenbrunner
* Dave Page
* Joe Conway
* Christophe Pettus

In case you want to reach out to the Infrastructure team please contact us at sysadmins@lists.postgresql.org

[[Category:Community]]

User:Mha

2020-07-02T20:12:21Z

Mastermind:

#blamemagnus

File:Elephant.png

2020-07-02T19:35:22Z

Mastermind:

== Licensing ==
{{The PostgreSQL Licence}}

Main Page

2020-07-02T19:32:04Z

Mastermind: update for translation plugin changes

__NOTOC__
{{Languages}}
= Welcome to the PostgreSQL Wiki! =

This wiki contains user documentation, how-tos, and tips 'n' tricks related to PostgreSQL. It also serves as a collaboration area for PostgreSQL contributors.

== User Documentation ==
* [[Frequently Asked Questions]]

==== Community Generated Articles, Guides, and Documentation ====
* [[Community Generated Articles, Guides, and Documentation|General articles and guides]]
* [[PostgreSQL Tutorials]]
* [[:Category:Snippets|PostgreSQL Related Code Snippets]]
* [[Detailed installation guides]]
* [[Converting from other Databases to PostgreSQL]]
* [[Comparison with other Database systems]]
* [[Database Administration and Maintenance]]
* [[Development Articles|Development with PostgreSQL]]
* [[Performance Optimization|PostgreSQL Performance Optimization]]
* [[PostgreSQL Related Slides and Presentations]]

==== Documentation on the main site ====
* [http://www.postgresql.org/docs/manuals/ PostgreSQL Manuals]
* [http://www.postgresql.org/docs/books/ PostgreSQL Books]

== Alternate Languages ==

The following pages contain user documentation in languages other than English.

* [[Main Page/de|deutsch]]
* [[Main Page/es|español]]
* [[Main Page/fr|français]]
* [[Main Page/he|עברית]]
* [[Main Page/ja|日本語]]
* [[Main Page/pt|português]]
* [[Main Page/ru|русский]]
* [[Main Page/zh|中文]]
* [[Main Page/zh-hant|中文（繁體]]

== Contributor Information ==
* You can find many PostgreSQL users and developers chatting in [irc://irc.freenode.net/postgresql #postgresql on freenode]. A list of IRC nick names with their respective real world names can be found [[IRC2RWNames | here]].
* [[Events | Upcoming Events]]
* [[Development information]]
* [[Advocacy]]

== User Accounts ==
* All activity on this site should follow the [[Policies|PostgreSQL Project Policies]].
* In order to edit or create documents on the site, you will need a [http://www.postgresql.org/community/signup PostgreSQL community account]. This is the same account used when submitting news or events on [http://www.postgresql.org www.postgresql.org].
'''NOTE: due to recent spam activity "editor" privileges are granted manually for the time being. If you just created a new community account or if your current account used to have "editor" privileges ask on either the [mailto:pgsql-www@postgresql.org PostgreSQL -www Mailinglist] or the [irc://irc.freenode.net/postgresql PostgreSQL IRC Channel] (direct your request to 'pginfra', multiple individuals in the channel highlight on that string) for help. Please include your community account name in those requests.

Template:Languages

2020-07-02T19:30:55Z

Mastermind:

== Template ==

<onlyinclude></onlyinclude>

== Syntax ==
<nowiki>{{Languages|PageName}}</nowiki>

* '''PageName''' (optional) - the name of the page to display language links for. If omitted then the English version of the current page is used. This parameter can normally be omitted, as it is only required if you want to link to a page other than the one you place the template on, which is very uncommon. If this parameter is used on a sub-page make sure you supply the root name, not the full page name (e.g. on [[MediaWiki/fr]] you would need to use <code><nowiki>{{Languages|MediaWiki}}</nowiki></code> and not <code><nowiki>{{Languages|MediaWiki/fr}}</nowiki></code>).

== Usage ==

The template should only be placed on pages that exist in more than one language, and it should be placed in the same location on each translation of the page.

The English version of a page is always the main version, with all other languages as sub-pages, named using the appropriate language code (see below).

For example, on the Main Page you would include the text <code><nowiki>{{Languages}}</nowiki></code>, both on [[Main Page]] itself, and on each of its language sub-pages. The template automatically creates links to any language sub-pages that exist, e.g. <tt>Main Page/ja<tt>, <tt>Main Page/fr</tt>, and ignores non-existant languages.

See [[Project:Language policy]] for further details about translating pages.

== Supported languages ==
This shows you the name of each language's sub-page (using ''Main Page'' as an example). Other languages may be added easily as necessary. Please use the appropriate [[meta:List of Wikipedias|prefix, as used on Wikipedia]] when adding a new language. Please do ''not'' add languages for which no pages exist yet, as this will increase the time needed to include the template without adding any benefit (languages are only displayed to the user when the relevant page exists).

The link on the language names goes to the Wikipedia in that language. '''If no Wikipedia in your language exists, do not add pages in that language to MediaWiki.org!''' This wiki is not the place for language advocacy - please go through the correct channels, and once your language has a Wikipedia then please return to add content here.

{| border="1" cellpadding="5"
! Page Name || Language
|-
| Main Page || [[:en:|English]]
|-
| Main Page'''/af''' || [[:af:|Afrikaans]]
|-
| Main Page'''/ar''' || [[:ar:|Arabic]]
|-
| Main Page'''/az''' || [[:az:|Azerbaijani]]
|-
| Main Page'''/bcc''' || Southern Balochi
|-
| Main Page'''/bg''' || [[:bg:|Bulgarian]]
|-
| Main Page'''/br''' || [[:br:|Breton]]
|-
| Main Page'''/ca''' || [[:ca:|Catalan]]
|-
| Main Page'''/cs''' || [[:cs:|Czech]]
|-
| Main Page'''/da''' || [[:da:|Danish]]
|-
| Main Page'''/de''' || [[:de:|German]]
|-
| Main Page'''/el''' || [[:el:|Greek]]
|-
| Main Page'''/es''' || [[:es:|Spanish]]
|-
| Main Page'''/fa''' || [[:fa:|Persian]]
|-
| Main Page'''/fi''' || [[:fi:|Finnish]]
|-
| Main Page'''/fr''' || [[:fr:|French]]
|-
| Main Page'''/gl''' || [[:gl:|Galician]]
|-
| Main Page'''/gu''' || [[:gu:|Gujarati]]
|-
| Main Page'''/he''' || [[:he:|Hebrew]]
|-
| Main Page'''/hu''' || [[:hu:|Hungarian]]
|-
| Main Page'''/id''' || [[:id:|Indonesian]]
|-
| Main Page'''/it''' || [[:it:|Italian]]
|-
| Main Page'''/ja''' || [[:ja:|Japanese]]
|-
| Main Page'''/ko''' || [[:ko:|Korean]]
|-
| Main Page'''/ksh''' || [[:ksh:|Kölsch]]
|-
| Main Page'''/ml''' || [[:mr:|Malayalam]]
|-
| Main Page'''/mr''' || [[:mr:|Marathi]]
|-
| Main Page'''/ms''' || [[:ms:|Malay]]
|-
| Main Page'''/nl''' || [[:nl:|Nederlands]]
|-
| Main Page'''/no''' || [[:no:|Norwegian]]
|-
| Main Page'''/oc''' || [[:oc:|Occitan]]
|-
| Main Page'''/pl''' || [[:pl:|Polish]]
|-
| Main Page'''/pt''' || [[:pt:|Portugese]]
|-
| Main Page'''/ro''' || [[:ro:|Romanian]]
|-
| Main Page'''/ru''' || [[:ru:|Russian]]
|-
| Main Page'''/si''' || [[:si:|Sinhalese]]
|-
| Main Page'''/sk''' || [[:sk:|Slovak]]
|-
| Main Page'''/sq''' || [[:sq:|Albanian]]
|-
| Main Page'''/sr''' || [[:sr:|Serbian]]
|-
| Main Page'''/sv''' || [[:sv:|Swedish]]
|-
| Main Page'''/ta''' || [[:ta:|Tamil]]
|-
| Main Page'''/th''' || [[:th:|Thai]]
|-
| Main Page'''/tr''' || [[:tr:|Turkish]]
|-
| Main Page'''/uk''' || [[:uk:|Ukrainian]]
|-
| Main Page'''/vi''' || [[:vi:|Vietnamese]]
|-
| Main Page'''/yue''' || [[:zh-yue:|Cantonese]]
|-
| Main Page'''/zh''' || [[:zh:|Chinese]]
|-
| Main Page'''/zh-hans''' || Chinese (Simplified)
|-
| Main Page'''/zh-hant''' || Chinese (Traditional)
|}

== Example ==
Here is how the language bar looks on the [[MediaWiki]] page:
{{Languages|MediaWiki}}
[[Category:Language templates]]

PGLister: How to Moderate

2020-03-02T18:35:29Z

Mastermind: /* Before you moderate for this first time */

{{Languages}}

[https://lists.postgresql.org/ PGLister] is a mailing list management system designed to better [[PGLister_Announce | address the needs]] of the PostgreSQL community. PGLister is updated to work with recent improvements in email technology and spam filtering as well as provide an easy-to-use interface to manage list access. The guide below explains how a moderator can manage lists assigned for moderation.

== Before you moderate for this first time ==

In order to be assigned as a moderator to lists managed by [https://lists.postgresql.org/ PGLister], you must have logged into PGLister at least once. You can follow these steps to log in:

# Visit [https://lists.postgresql.org/ PGLister] at [https://lists.postgresql.org/ https://lists.postgresql.org/]
# Click on [https://lists.postgresql.org/manage/ Manage Subscriptions]. '''If your community account is already authenticated, then you will be logged into PGLister and redirected to the PGLister dashboard. You are now done.'''
# If your account is not authenticated, you will be redirect to the community login page. Please log in with your community credentials here.
## If you do not have a community account, you will need to register for one. Follow the steps to register a community account. When you are finished with sign up, return to Step 1 of this guide.
# If you successfully authenticate your account, you will be redirect to the [https://lists.postgresql.org/manage/ PGLister Dashboard] where you can manage your PostgreSQL mailing list subscriptions as well as moderate lists.
# If this is the first time you authenticated with PGLister and/or would like to request to be added as a moderator to a mailing list, please contact [mailto:sysadmins@lists.postgresql.org sysadmins@lists.postgresql.org] with your requests details.

== Moderating Lists ==

If you are a moderator of any list on PGLister, you will have access to the [https://lists.postgresql.org/moderate/ moderation dashboard]. You can find the link to the moderation dashboard underneath the "Manage lists" heading on the [https://lists.postgresql.org/manage/ PGLister Dashboard]. Click "Moderate / Manage Lists" to access to the [https://lists.postgresql.org/moderate/ moderation dashboard].

Below will break down each section in the moderation dashboard and how to moderate the mailing lists you help manage.

=== The "Moderation" Screen ===

When mailing lists that you moderate have messages that require review, they will appear in the "Moderation" section of the moderation [https://lists.postgresql.org/moderate/ moderation dashboard]. As a moderator, you will also receive an email that provides several courses of action to take on the message. '''NOTE: THE EMAIL SENT TO MODERATORS REQUESTING MODERATION DOES NOT CONTAIN A MESSAGE PREVIEW.''' If you would like to preview the message before setting a course of action, you must visit the [https://lists.postgresql.org/moderate/ moderation dashboard] to view the message preview. Please see below for instructions on how to do so.

==== Moderation Metadata ====

The metadata on a message queued for moderation contains the following information:

* Date: When the message was sent
* List: Which list the message was sent to (e.g. "pgsql-announce")
* Reason: The reason why the message is in the moderation queue (e.g. "sender is not a subscriber of any list)

==== Moderation Message Info ====

The data contained in the "Message" section on the moderation dashboard includes the following:

* Sender: The email address ending the message
* Subject: The subject of the message. If you click on "Subject," a popover box appears that contains a preview of the message. Based on the email client used to send the message, this can at times appear to be garbled text.
* Message ID: Contains a URL that activates a popover with the message ID

==== Moderation Actions ====

The actions section determines what to do with the message. In other words, "Actions" comprises the moderator's decision with the message, such as whether or not it should be sent out to the list. Below is what each action does for a message:

* '''Ignore''': This is the default action. Ignore is a no-op: it does not perform any action on the message.
* '''Approve''': Approves the message to be sent to the list.
* '''Whitelist''': Both approve the message and add the sender's email address to the whitelist of that mailing list. '''NOTE: This means that a sender can ALWAYS send messages to the mailing list that are automatically approved without any moderation.'''
* '''Discard''': Removes the message from the moderation queue and does '''not''' send the message to the mailing list. The sender does '''not''' receive a notification that the message was not approved for sending. This is typically used for messages that are spam.
* '''Reject''': Prompts the moderator to enter a reason for rejecting the message to be delivered to the sender and removes the message from the moderation queue. This action does '''not''' send the message to the mailing list. The sender receives a notification that the message was not approved for sending as well as the reason why it was rejected. ''Please be polite with your responses'': someone sending an email to the list may not be aware of the list policy, so try to point them to the correct reference.
* '''Unsubscribe''': Unsubscribes the sender from the list. This requires the sender to be identified as an active subscriber of the list.
* '''Reject unsub''': The same as ''reject'', except the reason is set to a pre-canned message with full instructions for how to use the List headers to unsubscribe from a message. This is the appropriate choice when an unsubscribe request is received from a sender who is not identified as a subscriber of the list.

In order to finalize all the selected actions, a moderator must click '''Moderate''' at the bottom of the Moderation section.

===== Moderation Actions for pgsql-announce =====

Due to the large number of subscriptions to the pgsql-announce mailing list, a message sent to pgsql-announce must be approved by '''two''' moderators before it is sent through. This is to ensure that we respect the mailboxes of everyone subscribed to pgsql-announce and that a moderator does not accidentally approve a message that would be deemed as inappropriate for that list.

==== Explaining the Moderation email ====

It is also possible to moderate messages from an email sent to moderators of a list. You will probably want to see a preview of the message before applying a moderation action, but fortunately you can do this from the email. All actions are the same as [[#Moderation Actions|moderation actions]] described above, but as soon as you click on the URL, this action is taken. A few notes:

* '''Preview''': Brings you to a preview of the message. This opens up a tab in your browser with the contents of the message.
* '''Reject''': Reject is currently not supported from the moderation email. If you would like to provide a rejection reason for the message, you will have to view the moderation dashboard.

=== List Management Overview ===

The list management overview of the moderation screen is a list of the mailing lists that you moderate. If you click on one of the lists, you will be brought to the individual list management page.

== List Management ==

The list management section of PGLister enables a moderator to perform the following actions:

* View which email addresses are subscribed to the list. This also allows a moderator to unsubscribe email addresses from a list
* Subscribe new email addresses to the list
* Whitelist email addresses that are always allowed to post messages to the list

=== View/Unsubscribe ===

The view/unsubscribe portion of the list manager allows a moderator to see who is subscribed to a mailing list and have the option of unsubscribing those email addresses.

There is a box that allows for a moderator to search for an email address. If nothing is typed into the box, then all email addresses subscribed to that list are displayed in the next view. From there, a moderator can view the email addresses that are subscribed to the list as well as unsubscribe these particular email addresses.

=== Subscribe ===

The subscribe section allows a moderator to subscribe an email address to the list. If you are adding an email address using this method, please be sure that the owner of the email address has given you permission to do so as the email address will automatically be subscribed to the mailing list without any additional confirmation.

=== Whitelist ===

The whitelist section allows a moderator to manage email addresses that can always post to the particular email list without moderator approval. A moderator can also remove email addresses from the whitelist too. Please use this feature carefully. If you have any questions on how the whitelist works, please send an email to [mailto:sysadmins@postgresql.org sysadmins@postgresql.org].

Infrastructure team

2020-03-02T18:34:53Z

Mastermind: /* Infrastructure Team Members */

Handling Security Issues

2018-09-11T19:48:31Z

Mastermind: update list of current security team members

This page contains information for developers on how to deal with security issues and how to prepare a security release.

'''Note:''' If you are a user who wants to report a security issue or who wants to learn about how the PostgreSQL project deals with security issues, please go to http://www.postgresql.org/support/security. The wiki page you are looking at is aimed at developers.

== security@postgresql.org ==

The email address security@postgresql.org is the recommended contact point for all inquiries about security issues. It currently points at pgsql-security@postgresql.org.

== Security team ==

The security team is a closed-subscription list whose purpose is to be able to discuss security issues in a controlled group. The current members are:

* Álvaro Herrera
* Andres Freund
* Andrew Dunstan
* Bruce Momjian
* Dave Page
* Greg Stark
* Heikki Linnakangas
* Tatsuo Ishii
* Jonathan Katz
* Magnus Hagander
* Michael Paquier
* Noah Misch
* Peter Eisentraut
* Robert Haas
* Stephen Frost
* Simon Riggs
* Stefan Kaltenbrunner
* Tom Lane

== Responding to security bug reports ==

Respond to a security bug report reported via the security@ address in the same way as you would with a normal bug report on pgsql-bugs. The only difference is that the issue should not be disclosed to anyone outside the security team and the original reporter.

== Committing patches for security issues ==

If the git commit log message for a commit matches

/^Security:/

then the message on pgsql-committers will be held for moderation. This facility should be applied when committing a patch for a security issue, so that details of the fix don't get broadcast to the world before the release including the fix is made. See [http://archives.postgresql.org/pgsql-committers/2008-01/msg00100.php this example] for a commit message where this was done. As in that example, the recommended style is something like "Security: CVE-number" or some other reference to the reason for the security marker.

== CVE numbers ==

A CVE number should be requested for every security issue. This number should be included in all the commit messages, announcements, and so on. A document describing the process can be found on developer.postgresql.org at ~petere/can-request.txt (only available with shell access, because it is not a public document). The person who drives the process of fixing the issue and preparing the security release (often Tom Lane) is usually the one who deals with requesting the CVE numbers.

[[Category:Development]]

PostgreSQL wiki:About

2018-01-04T21:34:22Z

Mastermind:

This wiki serves as a repository for user-contributed PostgreSQL documentation. The PostgreSQL project does not endorse any of the documentation on this site; it provides the wiki as a means for users to share documentation and notes developed from their own experiences with PostgreSQL. By adding or editing any pages on this wiki, you agree to license your contributions under its [[PostgreSQL_wiki:Copyrights|copyright terms]].

The official PostgreSQL documentation can be found at [https://www.postgresql.org/docs https://www.postgresql.org/docs].

If you find any inappropriate pages on this site, please contact the [mailto:pgsql-www@postgresql.org PostgreSQL Web Team]

96releasedraft

2016-09-13T18:55:28Z

Mastermind: http->https

=PostgreSQL 9.6 Released=

PostgreSQL 9.6, the latest version of the world's leading open source SQL database, was released today by the PostgreSQL Global Development Group. This release will allow users to both scale up and scale out high performance database workloads. New features include parallel query, synchronous replication improvements, and phrase search.

==Scale Up with Parallel Query==

Version 9.6 adds support for parallelizing some query operations, enabling utilization of several or all of the cores on a server to return query results faster. This release includes parallel sequential (table) scan, aggregation, and joins. Depending on details and available cores, parallelism can speed up big data queries by as much as 32X.

"I migrated our entire genomics data platform - all 25 billion legacy MySQL rows of it - to a single Postgres database, leveraging the row compression abilities of the JSONB datatype, and the excellent GIN, BRIN, and Btree indexing modes. Now with version 9.6, I expect to harness the parallel query functionality to allow even greater scalability for queries against our rather large tables," said Mike Sofen, Chief Database Architect, Synthetic Genomics.

==Scale Out with Synchronous Replication and postgres_fdw==

Two new options have been added to PostgreSQL's synchronous replication feature which allow it to be used to maintain consistent reads across database clusters. First, it now allows configuring groups of synchronous replicas. Second, the "remote_apply" mode creates a more consistent view of data across multiple nodes. These features support using built-in replication to maintain a set of "identical" nodes for load-balancing read workloads.

The PostgreSQL-to-PostgreSQL data federation driver, postgres_fdw, has new capabilities to execute work on remote servers. By "pushing down" sorts, joins, and batch data updates, users can distribute workload across multiple PostgreSQL servers.

QUOTE ABOUT SCALING OUT ON POSTGRES HERE

==Better Text Search with Phrases==

PostgreSQL's full text search feature, tsearch, now supports "phrase search." This lets users search for exact phrases, or for words within a specified proximity to each other, using fast GIN indexes. Phrase search means that PostgreSQL continues to be an alternative to dedicated text search technologies for web search and data mining.

==Links==

* Downloads: https://www.postgresql.org/downloads
* Press Kit: https://www.postgresql.org/about/press/presskit96
* Release Notes: https://www.postgresql.org/documentation/current/static/release-9-6
* What's New in 9.6: https://wiki.postgresql.org/wiki/new_in_9.6

==About PostgreSQL==

PostgreSQL is the most advanced open source database system, with a global community of thousands of users and contributors and dozens of companies and organizations. The PostgreSQL Project builds on over 30 years of engineering, starting at the University of California, Berkeley, and has an unmatched pace of development today. PostgreSQL's mature feature set not only matches top proprietary database systems, but exceeds them in advanced database features, extensibility, security and stability. Learn more about PostgreSQL and participate in our community at: https://www.postgresql.org.

WikiEditing

2016-06-11T14:14:27Z

Mastermind: preset subject to help filtering

Editing this wiki now requires "editor" privileges.

If you just created a new community account or if your current account used to have "editor" privileges, you can ask on either the [mailto:pgsql-www@postgresql.org?subject=Wiki%20editor%20request PostgreSQL -www Mailinglist] or the [irc://irc.freenode.net/postgresql PostgreSQL IRC Channel] (direct your request to 'pginfra', multiple individuals in the channel highlight on that string) for "editor" privileges. Please include your community account name in those requests.

This is due, in large part, to recent spam activity.

WikiEditing

2016-01-24T19:12:12Z

Mastermind:

Editing this wiki now requires "editor" privileges.

If you just created a new community account or if your current account used to have "editor" privileges, you can ask on either the PostgreSQL -www Mailinglist or the PostgreSQL IRC Channel for "editor" privileges. Please include your community account name in those requests.

This is due, in large part, to recent spam activity.

MediaWiki:Sitenotice

2016-01-05T20:58:15Z

Mastermind: Created page with "'''NOTE: due to recent spam activity "editor" privileges are granted manually for the time being. If you just created a new community account or if your current account used t..."

'''NOTE: due to recent spam activity "editor" privileges are granted manually for the time being. If you just created a new community account or if your current account used to have "editor" privileges ask on either the [mailto://pgsql-www@postgresql.org PostgreSQL -www Mailinglist] or the [irc://irc.freenode.net/postgresql PostgreSQL IRC Channel] for help.

MediaWiki:Loginstart

2016-01-05T19:35:39Z

Mastermind: Created page with "NOTE: due to recent spam activity "editor" privileges are granted manually for the time being. If you just created a new community account or if your current account used to h..."

NOTE: due to recent spam activity "editor" privileges are granted manually for the time being. If you just created a new community account or if your current account used to have "editor" privileges ask on either the PostgreSQL -www Mailinglist or the PostgreSQL IRC Channel for help.

Main Page

2016-01-05T18:53:03Z

Mastermind: /* User Accounts */

__NOTOC__
= Welcome to the PostgreSQL Wiki! =

This wiki contains user documentation, how-tos, and tips 'n' tricks related to PostgreSQL. It also serves as a collaboration area for PostgreSQL contributors.

== User Documentation ==
* [[Frequently Asked Questions]]

==== Community Generated Articles, Guides, and Documentation ====
* [[Community Generated Articles, Guides, and Documentation|General articles and guides]]
* [[PostgreSQL Tutorials]]
* [[:Category:Snippets|PostgreSQL Related Code Snippets]]
* [[Detailed installation guides]]
* [[Converting from other Databases to PostgreSQL]]
* [[Comparison with other Database systems]]
* [[Database Administration and Maintenance]]
* [[Development Articles|Development with PostgreSQL]]
* [[Performance Optimization|PostgreSQL Performance Optimization]]
* [[PostgreSQL Related Slides and Presentations]]

==== Documentation on the main site ====
* [http://www.postgresql.org/docs/manuals/ PostgreSQL Manuals]
* [http://www.postgresql.org/docs/books/ PostgreSQL Books]

== Alternate Languages ==

The following pages contain user documentation in languages other than English.

* [[Chinese|中国]]

* [[Deutsch]]

* [[Español]]

* [[Français]]

* [[Japanese|日本]]

* [[Português]]

* [[Russian|Русский]]

== Contributor Information ==
* You can find many PostgreSQL users and developers chatting in [irc://irc.freenode.net/postgresql #postgresql on freenode]. A list of IRC nick names with their respective real world names can be found [[IRC2RWNames | here]].
* [[Events | Upcoming Events]]
* [[Development information]]
* [[Advocacy]]

== User Accounts ==
* All activity on this site should follow the [[Policies|PostgreSQL Project Policies]].
* In order to edit or create documents on the site, you will need a [http://www.postgresql.org/community/signup PostgreSQL community account]. This is the same account used when submitting news or events on [http://www.postgresql.org www.postgresql.org], or adding comments to the interactive version of the [http://www.postgresql.org/docs/ official documentation].
'''NOTE: due to recent spam activity "editor" privileges are granted manually for the time being. If you just created a new community account or if your current account used to have "editor" privileges ask on either the [mailto://pgsql-www@postgresql.org PostgreSQL -www Mailinglist] or the [irc://irc.freenode.net/postgresql PostgreSQL IRC Channel] for help.

Main Page

2016-01-05T18:52:34Z

Mastermind: /* User Accounts */

__NOTOC__
= Welcome to the PostgreSQL Wiki! =

This wiki contains user documentation, how-tos, and tips 'n' tricks related to PostgreSQL. It also serves as a collaboration area for PostgreSQL contributors.

== User Documentation ==
* [[Frequently Asked Questions]]

==== Community Generated Articles, Guides, and Documentation ====
* [[Community Generated Articles, Guides, and Documentation|General articles and guides]]
* [[PostgreSQL Tutorials]]
* [[:Category:Snippets|PostgreSQL Related Code Snippets]]
* [[Detailed installation guides]]
* [[Converting from other Databases to PostgreSQL]]
* [[Comparison with other Database systems]]
* [[Database Administration and Maintenance]]
* [[Development Articles|Development with PostgreSQL]]
* [[Performance Optimization|PostgreSQL Performance Optimization]]
* [[PostgreSQL Related Slides and Presentations]]

==== Documentation on the main site ====
* [http://www.postgresql.org/docs/manuals/ PostgreSQL Manuals]
* [http://www.postgresql.org/docs/books/ PostgreSQL Books]

== Alternate Languages ==

The following pages contain user documentation in languages other than English.

* [[Chinese|中国]]

* [[Deutsch]]

* [[Español]]

* [[Français]]

* [[Japanese|日本]]

* [[Português]]

* [[Russian|Русский]]

== Contributor Information ==
* You can find many PostgreSQL users and developers chatting in [irc://irc.freenode.net/postgresql #postgresql on freenode]. A list of IRC nick names with their respective real world names can be found [[IRC2RWNames | here]].
* [[Events | Upcoming Events]]
* [[Development information]]
* [[Advocacy]]

== User Accounts ==
* All activity on this site should follow the [[Policies|PostgreSQL Project Policies]].
* In order to edit or create documents on the site, you will need a [http://www.postgresql.org/community/signup PostgreSQL community account]. This is the same account used when submitting news or events on [http://www.postgresql.org www.postgresql.org], or adding comments to the interactive version of the [http://www.postgresql.org/docs/ official documentation].
'''NOTE: due to recent spam activity "editor" privileges are granted manually for the time being. If you just created a new community account or if your current account used to have "editor" privileges ask on either the [mailto://pgsql-www@postgresql.org PostgreSQL -www Mailinglist] or on the [irc://irc.freenode.net/postgresql PostgreSQL IRC Channel] for help.

AndroidAppContest

2015-07-10T19:03:28Z

Mastermind: Reverted edits by Lanita1223 (talk) to last revision by Boshomi

= PostgreSQL Android Application Contest =

We are having a contest to create an open source PostgreSQL application for the Android OS. The prize is a brand-new Nexus One phone generously donated by Google.

== Timeline ==

* April 25, 2010: contest announced
* July 6, 2010: entries due
* <strike>PDXPUG Day, OSCON, July 19</strike> OSCON 2010: winners announced

== Contestants ==

* Stephen Denne - [http://www.datacute.co.nz/pgquilt/pgquilt.html pgQuilt] ([http://www.datacute.co.nz/pgquilt/pgQuilt.apk .apk])
* Magnus Hagander - [http://github.com/mhagander/mailinglistmoderator Mailing List Moderator] ([http://github.com/downloads/mhagander/mailinglistmoderator/mailinglistmoderator.apk .apk])
* Roland Tritsch - [http://code.google.com/p/chargefinder/ ChargeFinder] ([http://chargefinder.googlecode.com/files/CFMain-V1.1.0.apk .apk])
* Mark Wong - [http://github.com/markwkm/PGTop/ PGTop] ([http://github.com/downloads/markwkm/PGTop/PGTop-1.1.apk .apk])
* Marek Wróbel & Albert Łącki - [http://users.v-lo.krakow.pl/~mwrobel/bcinventory/ Barcode Inventory] ([http://users.v-lo.krakow.pl/~mwrobel/bcinventory-media/download/BarcodeInventory.apk .apk])

== Prize ==

Winner: Brand-new developer version (unlocked) Nexus One phone from Google.

All participants who ''complete'' an app will get a Postgres 9 shirt.

Also, all participants will be blogged and announced.

== Rules ==

# The contest participant must have done the majority of the coding work on the application.
# The application can be anything which is functionally dependent on or complementary to PostgreSQL. This would include things like a simple PostgreSQL GUI or query creator, a PostGIS geo application, or similar.
# Applications which do not actually use the database, but are complementary to PostgreSQL use, such as an EXPLAIN ANALYZE viewer or PostgreSQL documentation searcher, are also permitted.
# PostgreSQL need not (and really should not) be run on the phone. For this reason, the application can depend on having a data connection.
# The source code must be distributed under an OSI-approved license, and delivered with the completed application to the contest judges. Source code will be distributed by the judges via a Git repo at git.postgresql.org. BSD or PostgreSQL license is preferred but not required.
# The application must be available in an Android-standard package, but submitting it for the Marketplace is not a requirement.
# You must live somewhere we can affordably ship the Nexus One from the USA and reasonably expect it to arrive intact. If in doubt, ask us.
# The application cannot already be available before April 15, 2010.
# All three judges must be able to install and try the application on their phones. This means making the application compatible with Android version 1 (likely 1.6 is good enough).

== Judges ==

*Josh Berkus ''(testing on both G1 and Nexus One)''
*Selena Deckelmann ''(testing on G1)''
*Matthew Momjian ''(testing on G1)''

== E-mail for Participation ==

Please join the [http://groups.google.com/group/pgandroid pgAndroid Google Group]

== Questions asked by participants ==

Q: Where can I find the android SDK?
A: http://developer.android.com/sdk/index.html

Q: What is the minimum SDK API level required? (i.e. is it sufficient to support android 1.6 to run on the G1 phones?)
A: 1.6 should be sufficient.

[[Category:Mobile appliction]]

HowToTranslate

2015-05-30T11:23:18Z

Mastermind: small typo fix

= How to Translate Releases =

This is a set of instructions for Regional Contacts (RCs) and Advocacy volunteers on how to translate major version releases and other PR materials for PostgreSQL. It is not about translating the web site or translating PostgreSQL itself.

== General Information ==

=== Procedure & Timeline ===

Generally you will have a very short time to get a release translated. The schedule generally goes like this:

# Day Minus 15: draft release send to Regional Contacts for questions and typo-spotting.
# Day Minus 12: release finalized, offered to RCs for translation
# Day Minus 6: draft copies of all languages checked in
# Day Minus 4: final versions of all languages checked in

Yes, that does mean that you need to have your translations finalized at least 4 days before the final release (and preferably earlier). This is because all Presskits need to be integrated into the www.postgresql.org infrastructure, checked, and corrected.

The translation cycle generally goes like this:

# Do draft translation
# Send it to your proofreader for corrections
# Correct mistakes
# Send it back to proofreader for check
# Send it in to Josh / check in to Git for HTML checking
# Correct HTML errors
# Finalize

=== Encoding ===

All translations of HTML documents must be UTF8 and not any other encoding. Our web infrastructure is UTF8 only.

=== ProofReading ===

All translations must be checked by someone ''other than the person who did the translation'' to look for mistakes in spelling, punctuation and grammar. It is not humanly possible to proofread your own work. Note that this proofreader does not need to be a PostgreSQL community member; they can just be a friend of yours who writes your language very well.

Stupid grammar and spelling mistakes reflect badly on the whole project and make us look amateur. Don't let them get out.

For the groups where several RCs have the same language, of course, the RCs can check each other's work.

=== Sharing Translation Work ===

RCs are strongly encouraged to share work on the translations with other community members, especially other RCs. Several languages, notably Spanish and German, have several RCs who share responsibility for them. It is up to you to figure out how to divide up the work; however, you must coordinate with each other because there will be only ''one'' Spanish presskit.

'''Warning: Do not, under any circumstances, post the contents of the press release to a public mailing list, forum, or blog while you are working on it!'''

Using closed, private archive mailing lists (such as translators@postgresql.org) is fine, but lists like pgsql-es-ayuda would be a mess. Don't do it.

== Files to Translate ==

There are ''two'' files you need to translate for a major version release. If you do not translate ''both'' of them, you won't be included in the release process. While the two do share text, it is formatted differently in each file and needs to be translated as a separate file.

=== release.translate.txt ===

This file is the text of the e-mail for Regional Contacts to send out on the day of the release. It is pure text for that reason, and is relatively short.

==== Customizations ====

Each RC will be customizing this text with their own contact information, you will notice a block in the middle of the text file which looks like this:

YOUR NAME HERE
YOUR @POSTGRESQL.ORG EMAIL HERE
YOUR PHONE NUMBER HERE
YOUR LOCALIZED WEB SITE HERE, IF ANY

You needn't translate this block, as it will be filled in by the RC when they send the e-mail (hopefully!). Also there is a dateline at the beginning of the release, like this:

DATE HERE: The PostgreSQL Global Development Group has released ...

You will need to replace the "DATE HERE" words with the translated final date when the final release date is confirmed, about 5 days from the actual release.

==== Git Users: Directories ====

Git Users: Under press/releases/9.3/ there should be a directory with your two-letter or four-letter language code, e.g. "fr", "jp", "pt_BR". If there is not, then create one. All of the files you translate will go in there.

==== Release File Name ====

When you are finished translating, you should rename this file to "release.XX.txt" where "XX" is your countries's ISO code. e.g. "release.br.txt" or "release.usa.txt".

=== presskit94.html ===

This file becomes the online Press Kit for the release. It includes the text of the e-mail release, as well as a collection of links, expanded quotes, and further information about PostgreSQL.

The difficulty with this file is that it's full of HTML markup which has been checked extensively by our web staff. As such, it's critically important that you translate the text ''without'' modifying any of the HTML tags at all, except for the Customization section below.

Save this file as "presskit94.html" in you country code directory (or just email it to Josh). That is, do not change the name; just change the directory.

Note: a couple of the links say "(English)". This is to indicate that the documents linked to will not be translated, and should contain a warning that the link goes to an English-language document.

en/presskit94.html is supplied as an example for you to look at.

==== Customizations ====

In the center of the page is the Contact section. You need to customize this section. First, you need to add links to your language/region's PostgreSQL community page:

<pre>Web Pages
<ul>
<li><a href="http://www.postgresql.org">PostgreSQL home page</a></li>
<li><a href="YOUR LOCALIZED POSTGRES PAGE">NAME OF YOUR LOCALIZED POSTGRES PAGE</a></li>
</ul></pre>

That second link needs to be customized to your local Postgres community page, like so:

<pre><li><a href="http://www.postgresql.org.br/">Comunidade Brasileira de PostgreSQL</a></li></pre>

If you are translating for a language which has multiple local websites (Spanish, German, Italian, etc.) then please add additional Listitems with the additional pages. If you do not have a localized web site, simply delete that line.

The second customization you need to make is here:

<pre>Press Inquiries
REGIONAL CONTACT NAME HERE 
<a href="RC@POSTGRESQL.ORG">REGIONAL CONTACT EMAIL HERE</a> 
REGIONAL CONTACT PHONE HERE</pre>

This is where you put other contact information for the regional contacts in your language. For example:

<pre>Guido Barosio 
<a href="ar@postgresql.org">ar@postgresql.org</a> 
Cell: +54911-6641-1945</pre>

If your language covers multiple Regional Contacts, then list them all, one after the other, in the above format, ordered alphabetically by region name. Example:

<pre>Argentina 
Guido Barosio 
<a href="ar@postgresql.org">ar@postgresql.org</a> 
Cell: +54911-6641-1945
Chile 
Álvaro Herrera 
<a href="alvherre@postgresql.org">alvherre@postgresql.org</a> 
Phone: +56-9-74990919

etc.
</pre>

See the English version of the release for a good example of multiple contacts.

== Translation Source Management ==

There are two ways to share and collaborate on editing translations: e-mail and git. If you are part of a translation "team" (e.g. Spanish) then you will need to pick ''one'' of these ways to use. Git is preferred for those who know how to use it, but e-mail is available if needed.

=== Translating by E-mail ===

Josh will send the Regional Contacts list the final copies of the translate files in an e-mailed zip archive, and later on any line-item edits you need to have if we have last-minute text fixes.

You then e-mail around copies of the files to your co-translators and proofreader(s), being careful to make sure each person has the most updated version. I suggest using version numbers to ensure this.

Then you rename the files appropriately, zip them (or bzip or gzip) into an archive, and e-mail them to Josh. The zipping of the files is important because it prevents e-mail clients and servers from mangling the encodings, which otherwise tends to happen.

=== Translating by CVS ===

We are no longer supporting CVS for translations.

=== Translating by git ===

The releases are also available from git.postgresql.org. Git is strongly recommended for translation teams (Spanish, German, etc.) in order to coordinate their activities. However, Git syntax and concepts are not intuitive, so you may not want to use it if you don't have prior experience.

In order to be able to commit your stuff from git, please follow this procedure:

# get a PostgreSQL Community Profile, if you don't have one already.
# add your ssh key to your Profile.
# e-mail Josh about being added to the git repo
# clone the git repo:

git clone ssh://git@git.postgresql.org/press.git

5. add your translation files, and then add them to git

mkdir releases/9.3/XX
... create the initial version of the files ...
git add releases/9.3/XX
git commit -a # make sure you only include the interesting files!

7. push a copy to the central repository

git commit -a
git push origin

If you are working with others, you will need to frequently "pull" a copy of your translations before doing work yourself:

git pull origin

When you are done with your translations, notify us using the translators@ list and we'll merge the branches.

Please also read [[Working With Git]]

[[Category:Advocacy]]

HowToTranslate

2015-05-30T11:22:27Z

Mastermind: typo

= How to Translate Releases =

This is a set of instructions for Regional Contacts (RCs) and Advocacy volunteers on how to translate major version releases and other PR materials for PostgreSQL. It is not about translating the web site or translating PostgreSQL itself.

== General Information ==

=== Procedure & Timeline ===

Generally you will have a very short time to get a release translated. The schedule generally goes like this:

# Day Minus 15: draft release send to Regional Contacts for questions and typo-spotting.
# Day Minus 12: release finalized, offered to RCs for translation
# Day Minus 6: draft copies of all languages checked in
# Day Minus 4: final versions of all languages checked in

Yes, that does mean that you need to have your translations finalized at least 4 days before the final release (and preferably earlier). This is because all Presskits need to be integrated into the www.postgresql.org infrastructure, checked, and corrected.

The translation cycle generally goes like this:

# Do draft translation
# Send it to your proofreader for corrections
# Correct mistakes
# Send it back to proofreader for check
# Send it in to Josh / check in to Git for HTML checking
# Correct HTML errors
# Finalize

=== Encoding ===

All translations of HTML documents must be UTF8 and not any other encoding. Our web infrastructure is UTF8 only.

=== ProofReading ===

All translations must be checked by someone ''other than the person who did the translation'' to look for mistakes in spelling, punctuation and grammar. It is not humanly possible to proofread your own work. Note that this proofreader does not need to be a PostgreSQL community member; they can just be a friend of yours who writes your language very well.

Stupid grammar and spelling mistakes reflect badly on the whole project and make us look amateur. Don't let them get out.

For the groups where several RCs have the same language, of course, the RCs can check each other's work.

=== Sharing Translation Work ===

RCs are strongly encouraged to share work on the translations with other community members, especially other RCs. Several languages, notably Spanish and German, have several RCs who share responsibility for them. It is up to you to figure out how to divide up the work; however, you must coordinate with each other because there will be only ''one'' Spanish presskit.

'''Warning: Do not, under any circumstances, post the contents of the press release to a public mailing list, forum, or blog while you are working on it!'''

Using closed, private archive mailing lists (such as translators@postgresql.org) is fine, but lists like pgsql-es-ayuda would be a mess. Don't do it.

== Files to Translate ==

There are ''two'' files you need to translate for a major version release. If you do not translate ''both'' of them, you won't be included in the release process. While the two do share text, it is formatted differently in each file and needs to be translated as a separate file.

=== release.translate.txt ===

This file is the text of the e-mail for Regional Contacts to send out on the day of the release. It is pure text for that reason, and is relatively short.

==== Customizations ====

Each RC will be customizing this text with their own contact information, you will notice a block in the middle of the text file which looks like this:

YOUR NAME HERE
YOUR @POSTGRESQL.ORG EMAIL HERE
YOUR PHONE NUMBER HERE
YOUR LOCALIZED WEB SITE HERE, IF ANY

You needn't translate this block, as it will be filled in by the RC when they send the e-mail (hopefully!). Also there is a dateline at the beginning of the release, like this:

DATE HERE: The PostgreSQL Global Development Group has released ...

You will need to replace the "DATE HERE" words with the translated final date when the final release date is confirmed, about 5 days from the actual release.

==== Git Users: Directories ====

Git Users: Under press/releases/9.3/ there should be a directory with your two-letter or four-letter language code, e.g. "fr", "jp", "pt_BR". If there is not, then create one. All of the files you translate will go in there.

==== Release File Name ====

When you are finished translating, you should rename this file to "release.XX.txt" where "XX" is your countries's ISO code. e.g. "release.br.txt" or "release.usa.txt".

=== presskit94.html ===

This file becomes the online Press Kit for the release. It includes the text of the e-mail release, as well as a collection of links, expanded quotes, and further information about PostgreSQL.

The difficulty with this file is that it's full of HTML markup which has been checked extensively by our web staff. As such, it's critically important that you translate the text ''without'' modifying any of the HTML tags at all, except for the Customization section below.

Save this file as "presskit94.html" in you country code directory (or just email it to Josh). That is, do not change the name; just change the directory.

Note: a couple of the links say "(English)". This is to indicate that the documents linked to will not be translated, and should contain a warning that the link goes to an English-language document.

en/presskit94.html is supplied as an example for you to look at.

==== Customizations ====

In the center of the page is the Contact section. You need to customize this section. First, you need to add links to your language/region's PostgreSQL community page:

<pre>Web Pages
<ul>
<li><a href="http://www.postgresql.org">PostgreSQL home page</a></li>
<li><a href="YOUR LOCALIZED POSTGRES PAGE">NAME OF YOUR LOCALIZED POSTGRES PAGE</a></li>
</ul></pre>

That second link needs to be customized to your local Postgres community page, like so:

<pre><li><a href="http://www.postgresql.org.br/">Comunidade Brasileira de PostgreSQL</a></li></pre>

If you are translating for a language which has multiple local websites (Spanish, German, Italian, etc.) then please add additional Listitems with the additional pages. If you do not have a localized web site, simply delete that line.

The second customization you need to make is here:

<pre>Press Inquiries
REGIONAL CONTACT NAME HERE 
<a href="RC@POSTGRESQL.ORG">REGIONAL CONTACT EMAIL HERE</a> 
REGIONAL CONTACT PHONE HERE</pre>

This is where you put other contact information for the regional contacts in your language. For example:

<pre>Guido Barosio 
<a href="ar@postgresql.org">ar@postgresql.org</a> 
Cell: +54911-6641-1945</pre>

If your language covers multiple Regional Contacts, then list them all, one after the other, in the above format, ordered alphabetically by region name. Example:

<pre>Argentina 
Guido Barosio 
<a href="ar@postgresql.org">ar@postgresql.org</a> 
Cell: +54911-6641-1945
Chile 
Álvaro Herrera 
<a href="alvherre@postgresql.org">alvherre@postgresql.org</a> 
Phone: +56-9-74990919

etc.
</pre>

See the English version of the release for a good example of multiple contacts.

== Translation Source Management ==

There are two ways to share and collaborate on editing translations: e-mail and git. If you are part of a translation "team" (e.g. Spanish) then you will need to pick ''one'' of these ways to use. Git is preferred for those who know how to use it, but e-mail is available if needed.

=== Translating by E-mail ===

Josh will send the Regional Contacts list the final copies of the translate files in an e-mailed zip archive, and later on any line-item edits you need to have if we have last-minute text fixes.

You then e-mail around copies of the files to your co-translators and proofreader(s), being careful to make sure each person has the most updated version. I suggest using version numbers to ensure this.

Then you rename the files appropriately, zip them (or bzip or gzip) into an archive, and e-mail them to Josh. The zipping of the files is important because it prevents e-mail clients and servers from mangling the encodings, which otherwise tends to happen.

=== Translating by CVS ===

We are no longer supporting CVS for translations.

=== Translating by git ===

The releases are also available from git.postgresql.org. Git is stongly recommended for translation teams (Spanish, German, etc.) in order to coordinate their activities. However, Git syntax and concepts are not intuitive, so you may not want to use it if you don't have prior experience.

In order to be able to commit your stuff from git, please follow this procedure:

# get a PostgreSQL Community Profile, if you don't have one already.
# add your ssh key to your Profile.
# e-mail Josh about being added to the git repo
# clone the git repo:

git clone ssh://git@git.postgresql.org/press.git

5. add your translation files, and then add them to git

mkdir releases/9.3/XX
... create the initial version of the files ...
git add releases/9.3/XX
git commit -a # make sure you only include the interesting files!

7. push a copy to the central repository

git commit -a
git push origin

If you are working with others, you will need to frequently "pull" a copy of your translations before doing work yourself:

git pull origin

When you are done with your translations, notify us using the translators@ list and we'll merge the branches.

Please also read [[Working With Git]]

[[Category:Advocacy]]

RPM Packaging

2015-05-12T18:38:55Z

Mastermind:

=== How are RPMs packaged? ===

This was written by Lamar Owen and Devrim Gündüz, 2006-10-16, rewritten 2014-09 by Craig Ringer.

A git repository is maintained at http://git.postgresql.org/gitweb/?p=pgrpms.git, which for each package contains:

# A set of patches to make certain portions of the sources conform more closely with how Red Hat packages its own matching RPMs, better integrate into multiarch installs, etc;
# The initscript / systemd service file;
# Any other ancillary scripts and files;
# A README.rpm-dist document that tries to adequately document both the differences between the RPM build and the WHY of the differences, as well as useful RPM environment operations (like, using syslog, upgrading, getting postmaster to start at OS boot, etc);
# The spec file that throws it all together, specifying what files are in what subpackages, the version, dependencies, and a lot more.

A given "package" like PostgreSQL will have many copies of the above, one for each distro release and PostgreSQL version. For example, the package for PostgreSQL 9.4 on Fedora 20 is in <tt>9.4/postgresql/F-20</tt>

The PGDG RPM maintainer builds the SRPM, then executes RPM builds on a variety of build worker machines and pushes the resulting RPMs and SRPMs to http://yum.postgresql.org/srpms/$version/$distro/$distro-$release-$arch/ and http://yum.postgresql.org/$version/$distro/$distro-$release-$arch/ , e.g. http://yum.postgresql.org/srpms/9.4/fedora/fedora-20-x86_64/ and http://yum.postgresql.org/9.4/fedora/fedora-20-x86_64/ .

The Yum repository metadata is then updated so that yum can find the new packages.

[[Category:Linux distribution]]

Error logging in COPY

2015-05-12T18:35:15Z

Mastermind: Reverted edits by Phuongnh2 (talk) to last revision by Boshomi

== History ==

Error logging in COPY was a proposed feature developed by Aster Data against the PostgreSQL 9.0 code base. It was submitted and reviewed ([https://commitfest.postgresql.org/action/patch_view?id=173 1]) but not accepted into the core product for that or any other version so far.

== Overview ==

The purpose of error logging in COPY is to prevent the backend from erroring out if a malformed tuple is encountered during a COPY operation. Bad tuples can either be skipped or logged into an error logging table.

The format of the error logging table is as follows:

<source lang="SQL">
CREATE TABLE error_logging_table(
tupletimestamp TIMESTAMP WITH TIME ZONE,
targettable VARCHAR,
dmltype CHAR(1),
errmessage VARCHAR,
sqlerrcode CHAR(5),
label VARCHAR,
key BIGINT,
rawdata BYTEA
);
</source>

The COPY command returns the number of successfully copied tuples only.

== COPY options ==

Error logging is set by adding options to the COPY command. Here is the list of the available options:

{| border="1"
|Variable name
|Description
|Default value
|-
|ERROR_LOGGING
|Enables error handling for COPY commands (when set to true).
|true
|-
|ERROR_LOGGING_SKIP_BAD_ROWS
|Enables the ability to skip malformed tuples that are encountered in COPY commands (when set to true).
|true
|-
|ERROR_LOGGING_MAX_ERRORS
|Maximum number of bad rows to log before stopping the COPY operation (0 means unlimited).
|0
|-
|ERROR_LOGGING_SCHEMA_NAME
|Schema name of the table where malformed tuples are inserted by the error logging module
|'public'
|-
|ERROR_LOGGING_TABLE_NAME
|Relation name where malformed tuples are inserted by the error logging module. The table is automatically created if it does not exist.
|'error_table'
|-
|ERROR_LOGGING_LABEL
|Optional label that is used to identify malformed tuples
|COPY command text
|-
|ERROR_LOGGING_KEY
|Optional key to identify malformed tuples
|Index of the tuple in the COPY stream
|}

Bad tuples can be rejected for a number of reasons (extra or missing column, constraint violation, ...). The error table tries to capture as much context as possible about the error. If the table does not exist it is created automatically. The format of the error logging table is as follows:

<source lang="SQL">
CREATE TABLE error_logging_table(
tupletimestamp TIMESTAMP WITH TIME ZONE,
targettable VARCHAR,
dmltype CHAR(1),
errmessage VARCHAR,
sqlerrcode CHAR(5),
label VARCHAR,
key BIGINT,
rawdata BYTEA
);
</source>

tupletimestamp stores the time at which the error occured. targettable describes the table in which the row was inserted when the error occured. The exact error message and sql error code are recorded in errmessage and sqlerrcode, respectively. The original data of the row can be found in rawdata.

== Example ==

<source lang="SQL">
CREATE TEMP TABLE foo (a bigint, b text);
</source>

-- input_file.txt --
<source lang="text">
1 one
2
3 three 111
four 4
5 five
</source>
-- end of input_file.txt --

===error logging off===
<source lang="SQL">
COPY foo FROM 'input_file.txt';
</source>
<pre>
ERROR: missing data for column "b"
CONTEXT: COPY foo, line 2: "2"
</pre>
===skip bad rows===
<source lang="SQL">
--skip bad rows
COPY foo FROM 'input_file.txt' (ERROR_LOGGING, ERROR_LOGGING_SKIP_BAD_ROWS);
SELECT * from foo;
</source>
<pre>
a | b
---+------
1 | one
5 | five
(2 rows)
</pre>
===turn error logging on (default logs in error_logging_table)===
<source lang="SQL">
--turn error logging on (default logs in error_logging_table)
COPY foo FROM 'input_file.txt' (ERROR_LOGGING);
SELECT * from foo;
</source>
<pre>
a | b
---+------
1 | one
5 | five
(2 rows)
</pre>
<source lang="SQL">
SELECT * FROM error_logging_table;
</source>
<pre>
key | tupletimestamp | label | targettable | dmltype | errmessage | sqlerrcode | rawdata
-----+-------------------------------------+---------------------------------+---------------+---------+------------------------------------------+------------+--------------------------
2 | Thu Sep 10 07:09:17.869521 2009 PDT | COPY foo FROM 'input_file.txt'; | pg_temp_2.foo | C | missing data for column "b" | 22P04 | \x32
3 | Thu Sep 10 07:09:17.86953 2009 PDT | COPY foo FROM 'input_file.txt'; | pg_temp_2.foo | C | extra data after last expected column | 22P04 | \x3309746872656509313131
4 | Thu Sep 10 07:09:17.869538 2009 PDT | COPY foo FROM 'input_file.txt'; | pg_temp_2.foo | C | invalid input syntax for integer: "four" | 22P02 | \x666f75720934
(3 rows)
</pre>

===Redirect to another table with a specific label===
<source lang="SQL">
-- Redirect to another table with a specific label
COPY foo FROM 'input_file.txt' (ERROR_LOGGING, ERROR_LOGGING_SCHEMA_NAME 'error', ERROR_LOGGING_TABLE_NAME 'table1', ERROR_LOGGING_LABEL 'batch1');
SELECT * FROM error.table1;
</source>
<pre>
key | tupletimestamp | label | targettable | dmltype | errmessage | sqlerrcode | rawdata
-----+-------------------------------------+--------+---------------+---------+------------------------------------------+------------+--------------------------
2 | Thu Sep 10 07:09:17.869521 2009 PDT | batch1 | pg_temp_2.foo | C | missing data for column "b" | 22P04 | \x32
3 | Thu Sep 10 07:09:17.86953 2009 PDT | batch1 | pg_temp_2.foo | C | extra data after last expected column | 22P04 | \x3309746872656509313131
4 | Thu Sep 10 07:09:17.869538 2009 PDT | batch1 | pg_temp_2.foo | C | invalid input syntax for integer: "four" | 22P02 | \x666f75720934
(3 rows)
</pre>
===Limit to 2 bad rows: ===
<source lang="SQL">
-- Limit to 2 bad rows:
COPY foo FROM 'input_file.txt' (ERROR_LOGGING, ERROR_LOGGING_MAX_ERRORS 2);
</source>
<pre>
ERROR: invalid input syntax for integer: "four"
CONTEXT: COPY foo, line 4, column a: "four"
</pre>
<source lang="SQL">
SELECT count(*) from error_logging_table;
</source>
<pre>
count
-------
0
(1 row)
</pre>

[[Category:SQL]]

PgCon 2015 Developer Unconference

2015-04-16T19:18:15Z

Mastermind: /* RSVPs */

An Unconference-style multi-track (three tracks are currently planned) event for active PostgreSQL developers will be held from the afternoon of Tuesday 16 June, 2015 through Wednesday 17 June 2015 at the University of Ottawa, as part of PGCon 2015. This Unconference will be focused on technical PostgreSQL development discussions ranging from Clustering and replication to the infrastructure which runs postgresql.org.

== Topics ==

Developers are asked to propose topics which they wish to either present on or which they would like another individual to present on. All topics should be clearly related to PostgreSQL development. The topic should be added to the table below and any required attendees (presumably at least the presenter, and the requester if different) listed. Other attendees of the Unconference who are interested should list themselves as Optional. Note that non-technical topics related to PostgreSQL development will be addressed during the invite-only Developer meeting, being held in advance of the Unconference. Further, the Developer Unconference is for developers of PostgreSQL and user-oriented topics are not appropriate for this venue.

== Slot assignment ==

Slots will be assigned based on the topic's interest among the attendees of the Unconference (the number of individuals who listed themselves as attendees). Final determination on any particular topic will be made by the Unconference organizers. Please only participate if you are confident of your attendance at the Unconference.

== Venue ==

These meetings will be held at the University of Ottawa. The topics selected, the schedule and the specific room assignments will be published closer to the event and will be based on the information provided here. Please direct any questions to Dave Page (dpage@pgadmin.org).

== Attendees ==

While the Unconference is open to all attendees of PGCon, formal invitations will be sent to specific PostgreSQL developers, including the Core team, Major Contributors, Committers, and other developers who have been involved in the 9.4 release. These invitations are intended to encourage developers to attend the Unconference but we are unable to guarantee every invitee a speaking slot.

== RSVPs ==

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

* Josh Berkus
* Stephen Frost
* Stefan Kaltenbrunner
* Dave Page

=Topics=

{| border="1" cellpadding="4" cellspacing="0"
!Topic
!Policy
!Taker of Notes
!Required Attendees
!Optional Attendees

|- style="background-color:lightgray;"
|Clustering
|Open
|
|Josh Berkus
|

|- style="background-color:lightgray;"
|pgAdmin4
|Open
|
|Dave Page, Stephen Frost
|

|- style="background-color:lightgray;"
|Infrastructure Q&A
|Open
|
|Dave Page, Stephen Frost, Stefan Kaltenbrunner
|

|- style="background-color:lightgray;"
|WWW Team Meeting
|Open
|
|Dave Page, Stephen Frost, Stefan Kaltenbrunner
|

|- style="background-color:lightgray;"
|Advocacy Team Meeting
|Open
|
|Stephen Frost
|

|- style="background-color:lightgray;"
|Security Team Meeting
|Closed
|
|Heikki Linnakangas, Stephen Frost
|
|}

== Clustering ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

== pgAdmin4 ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

== Infrastructure Q&A ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

== WWW Team Meeting ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

== Advocacy Team Meeting ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

== Security Team Meeting ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

PgCon 2015 Developer Unconference

2015-04-16T19:17:59Z

Mastermind: /* Topics */

An Unconference-style multi-track (three tracks are currently planned) event for active PostgreSQL developers will be held from the afternoon of Tuesday 16 June, 2015 through Wednesday 17 June 2015 at the University of Ottawa, as part of PGCon 2015. This Unconference will be focused on technical PostgreSQL development discussions ranging from Clustering and replication to the infrastructure which runs postgresql.org.

== Topics ==

Developers are asked to propose topics which they wish to either present on or which they would like another individual to present on. All topics should be clearly related to PostgreSQL development. The topic should be added to the table below and any required attendees (presumably at least the presenter, and the requester if different) listed. Other attendees of the Unconference who are interested should list themselves as Optional. Note that non-technical topics related to PostgreSQL development will be addressed during the invite-only Developer meeting, being held in advance of the Unconference. Further, the Developer Unconference is for developers of PostgreSQL and user-oriented topics are not appropriate for this venue.

== Slot assignment ==

Slots will be assigned based on the topic's interest among the attendees of the Unconference (the number of individuals who listed themselves as attendees). Final determination on any particular topic will be made by the Unconference organizers. Please only participate if you are confident of your attendance at the Unconference.

== Venue ==

These meetings will be held at the University of Ottawa. The topics selected, the schedule and the specific room assignments will be published closer to the event and will be based on the information provided here. Please direct any questions to Dave Page (dpage@pgadmin.org).

== Attendees ==

While the Unconference is open to all attendees of PGCon, formal invitations will be sent to specific PostgreSQL developers, including the Core team, Major Contributors, Committers, and other developers who have been involved in the 9.4 release. These invitations are intended to encourage developers to attend the Unconference but we are unable to guarantee every invitee a speaking slot.

== RSVPs ==

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

* Josh Berkus
* Stephen Frost
* Dave Page

=Topics=

{| border="1" cellpadding="4" cellspacing="0"
!Topic
!Policy
!Taker of Notes
!Required Attendees
!Optional Attendees

|- style="background-color:lightgray;"
|Clustering
|Open
|
|Josh Berkus
|

|- style="background-color:lightgray;"
|pgAdmin4
|Open
|
|Dave Page, Stephen Frost
|

|- style="background-color:lightgray;"
|Infrastructure Q&A
|Open
|
|Dave Page, Stephen Frost, Stefan Kaltenbrunner
|

|- style="background-color:lightgray;"
|WWW Team Meeting
|Open
|
|Dave Page, Stephen Frost, Stefan Kaltenbrunner
|

|- style="background-color:lightgray;"
|Advocacy Team Meeting
|Open
|
|Stephen Frost
|

|- style="background-color:lightgray;"
|Security Team Meeting
|Closed
|
|Heikki Linnakangas, Stephen Frost
|
|}

== Clustering ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

== pgAdmin4 ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

== Infrastructure Q&A ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

== WWW Team Meeting ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

== Advocacy Team Meeting ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

== Security Team Meeting ==

=== Meeting Notes ===
* To be filled in

=== Attendees ===
* To be filled in

User:Mastermind

2014-11-06T18:58:50Z

Mastermind:

I'm Stefan Kaltenbrunner - you can reach me in #postgresql under the nick mastermind or simply send an email to stefan@kaltenbrunner.cc.

Infrastructure team

2014-05-30T21:24:24Z

Mastermind: sync with reality

Talk:Main Page

2014-05-30T18:30:36Z

Mastermind: Reverted edits by Empowerusauz (talk) to last revision by Mastermind

Hi All,

Does PostgreSQL run on Sun Solaris SPARC ?

----

To be consistent, I suggest changing "日本" (Japan, the country) to "日本語" (Japanese, the language) in the "Alternate Languages" section. [[User:Nicolas.barbier|Nicolas.barbier]] 21:01, 22 May 2011 (UTC)
-----------------------------------------------------------------------
Hi ALL

I have added big para on '''BigreSQL''', But look like it is not saved hence writing once again.
Bigresql = PostgreSQL engine + ProgresDB + BigData

That is what I have visulazing and I am finding it is future for Postgres as opensource DB and it can take on any Appliance in that case and also support the Schema free Database.

I have complete a though process on this. I am interested to development of same
before that I like to get community view on this,

Depend on response I will start giving detail design here. though I have already submiited my thought to Posgres Development team also.

Cheers
Jayant Dani
Solution Archiect
Head of CoE Technology (Big Data, Mobility, Portal)
TCS
Jayant.dani@tcs.com

Running & Installing PostgreSQL On Native Windows

2013-12-15T10:44:17Z

Mastermind: Undo revision 21558 by Busyguru (talk) spam

{{Languages}}

== Supported Platforms ==
=== What versions of Windows does PostgreSQL run on?===

PostgreSQL is supported on Windows XP and above, at least as of version 9.0. It will run on 32 and 64 bit systems.

Versions of the server are not tested on new operating system versions that are released after a newer major version of the server was released. For example, Windows 7 was released after PostgreSQL 8.4, so PostgreSQL 8.3 will not be supported on it. Similarly, when the upcoming RHEL 6 is released, only PostgreSQL 9.0.x will be supported on it. We aim to support new versions of Windows in the PostgreSQL major version following their release at the latest.

For information about platforms supported by the One-click installer, please see the installer download page, off the main [http://www.postgresql.org/download/windows download page for windows].

For information on non-Windows platforms see the [[FAQ|main FAQ]] and the [http://www.postgresql.org/download/ main download page].

=== What Windows platforms are NOT supported? ===

The PostgreSQL installers are not tested or supported on:

* Windows XP Embedded
* Windows 2000
* Windows NT 4
* Windows NT 3.5.x
* Windows 95/98/ME/3.x
* Windows CE
* Windows Mobile

These platforms are not supported. Please do not ask the mailing list for help with any of these platforms.

Please read the troubleshooting notes on [[Troubleshooting Installation#Installation fails on windows embedded|installation on embedded versions of windows]] for some more information about embedded windows.

=== I heard that NT4 and Windows 2000 are supported. Is that true? ===
Although not officially supported, PostgreSQL may run on Windows NT4 and Windows 2000
with a few minor issues including:
* The installer may not work correctly, thus you will need to install PostgreSQL manually from the binary .zip release, or compile it yourself.
* PostgreSQL uses a feature in the NTFS filesystem called 'reparse points' to implement tablespaces. Reparse points are not available in NT4, hence tablespaces cannot be used on NT4.
* There is no 'runas.exe' included in Windows NT4 as standard, making it difficult to start PostgreSQL from an administrative account.
It should also be noted that very little testing has been done on NT4.
* No testing is done on Windows NT 4 or Windows 2000, so newer versions may not work on these platforms.

Please do not ask for help with these obsolete platforms on the mailing list. Some of the [http://www.postgresql.org/support/professional_support professional support] companies may be able to assist you, though.

=== What about Windows 95/98/ME? ===

PostgreSQL requires functionality that is not available on these
platforms and will not run on them. If you need to run PostgreSQL
on these platforms, you can look at the
[http://www.postgresql.org/files/documentation/faqs/text/FAQ_CYGWIN Cygwin]
port, which has basic support for 9x platforms.

=== Is there a 64-bit build of PostgreSQL for Windows? ===

Yes. A [[64bit Windows port]] was released for [[PostgreSQL 9.0]].

32-bit builds of previous versions of PostgreSQL generally run fine on 64-bit Windows. Though they cannot practically use more than about 1GB of shared_buffers directly, they can still benefit from more than 4GB of memory because the Windows kernel will use that memory to cache disk reads.

=== What about 64-bit ODBC drivers? ===

At time of writing there was 64-bit support in the [http://psqlodbc.projects.postgresql.org/ psqlODBC] source code, but no official binary releases of 64-bit ODBC drivers. Check the psqlODBC website for details.

== Installation ==

=== What do I need to install PostgreSQL on Windows? ===

See [http://www.postgresql.org/download/windows the PostgreSQL for Windows download page] for various ways to download and install PostgreSQL on Windows.

The easiest way to install PostgreSQL on Windows is with the
One Click installer package maintained by EnterpriseDB, which you can get from the page linked to above. This will install PostgreSQL along with
pgAdmin (a graphical administration and management program), a selection of 'contrib' modules to provide additional specialised functionality, and a choice of procedural languages. A program called StackBuilder will be installed to help you download and install any additional components, like ODBC or JDBC drivers, that you may need.

=== What do I need to compile PostgreSQL from source code? ===

See the [http://www.postgresql.org/docs/current/static/install-windows.html documentation]
for instructions on how to compile PostgreSQL for windows, including details about supported compilers and tools.

=== Why do I need a non-administrator account to run PostgreSQL under? ===

When a hacker gains entry to a computer using a software bug in a
package, she gains the permissions of the user account under which the
service is run. Whilst we do not know of any such bugs in PostgreSQL,
we enforce the use of a non-administrative service account to minimise
the possible damage that a hacker could do should they find and utilise
a bug in PostgreSQL to hack the system.

This has long been common practice in the Unix world, and is starting to
become standard practice in the Windows world as well as Microsoft and
other vendors work to improve the security of their systems.

Note, that with the release of PostgreSQL 8.2, it is possible to run under
a administrative account. PostgreSQL 8.2 and above are able to irrevocably
give up administrative rights at startup, thus ensuring the rest of the
system remains secure in the extremely unlikely event that PostgreSQL
becomes compromised.

=== Can I install PostgreSQL on a FAT partition? ===

Use of PostgreSQL on FAT32 file systems is not supported or tested, because
FAT32 is a terrible file system on which to run ''any'' database.

PostgreSQL's number one priority is the integrity of your data. FAT and
FAT32 filesystems simply do not offer the reliability or crash-safety required.
In addition, the lack of security features offered by FAT make it
impossible to secure the raw data files from unauthorised modification.
Finally, PostgreSQL utilises a feature called 'reparse points' to
implement tablespaces. This feature is not available on FAT partitions.

The NTFS file system is a journalled filesystem offering much better
reliability and crash recovery. In addition, it has a comprehensive
access control system and offers the reparse point functionality used
by PostgreSQL.

For this reason, the PostgreSQL installer package will not initialise
a database cluster on anything but an NTFS partition. The server and
utilities may be installed on any partition type.

It is recognised however, that in rare cases FAT partitions may be the only choice.
In such cases, you can simply install PostgreSQL as normal, but without initialising the
database cluster. When the installation has finished, manually run
the 'initdb.exe' program on the FAT partition. Security and
reliability will be compromised however, and any attempts to create
tablespaces will fail. Do not use PostgreSQL on FAT32 in production.

The most common reason people ask this is when they have a USB key or external hard drive and they want to put a PostgreSQL database on it. Don't do it. You can format USB keys and external hard drives with NTFS, and you should do so if you want to run a database on them. FAT is not crash-safe, and removing a hard drive without using "Safely remove..." in Windows counts as a crash as far as the hard drive is concerned. Corruption is extremely likely. It is very important to reformat a removable drive with NTFS if it is to be used with PostgreSQL to store any data you care about.

=== What filesystem permissions does PostgreSQL require? ===
The PostgreSQL service account needs ''read'' permissions on
all directories leading up to the service directory. It needs ''write'' permissions ''only''
on the data directory. Specifically, it should ''not'' be granted anything other than ''read''
permissions on the directories containing binary files. (All directories below the installation
directory are set by the installer, so unless you change something, there should be no problem with this).

PostgreSQL also needs ''read'' permissions on system DLL files like kernel32.dll and user32.dll
(among others), which is normally granted by default, and on the CMD.EXE binary, which may in some
scenarios be locked down and need opening.

If you are running PostgreSQL on a multi-user system, you should remove the permissions from all
non-administrative users from the PostgreSQL directories. No user ''ever'' needs permissions on the
PostgreSQL files - all communication is done through the libpq connection. Direct access to data files
can lead to information disclosure or system instability!

=== Why can't I select Unicode as an encoding? ===

Starting with PostgreSQL 8.1, the UTF-8 unicode encoding is fully supported on Windows. The Unicode ODBC driver supports UTF-16, and the JDBC driver also has full unicode support.

The PostgreSQL server does not support the 2-byte UTF-16 or 4-byte UTF-32 Unicode encodings for internal data storage or on-the-wire communication. Beause UTF-16 is the default encoding on Windows, and what people on Windows usually mean when they say "Unicode", you might expect this to be a problem, but in practice it's fine, as the ODBC and JDBC drivers take care of this. Programs using libpq directly need to be aware of this, but not much else does.

=== I installed in a non-english language, but all messages show up in english! ===
The language choice made during the installation only selects which language is used by the installer. To
change the language of the messages of the installed product, make sure you have installed the ''National language
support'' feature. Then edit your postgresql.conf file and change the value of the ''lc_messages'' parameter
to the language you want.

== Common installation errors ==

=== PostgreSQL and/or the installer crashes at startup, fails to start or hangs on start ===

By far most common reasons for installation and runtime problems with PostgreSQL on Windows are Windows Scripting Host issues, antivirus software problems and 3rd-party (non-Microsoft) software firewalls. People also sometimes have trouble with the postgres service account password.

The following articles cover these issues. Please read them and follow their instructions before asking for help with installer problems.

==== Antivirus software ====

If you have any antivirus software installed, you '''must''' exclude the data directories that are to be used by PostgreSQL and '''must''' exclude postgresql.exe process. If that still does not help, it may be required to completely uninstall the antivirus software from the machine.

Antivirus software can interfere with PostgreSQL's operation, because PostgreSQL requires file access commands in Windows to behave exactly as documented by Microsoft, and many antivirus programs contain errors or accidental behavior changes that cause these commands to misbehave subtly. Most programs do not care because they access files in fairly simple ways. Because PostgreSQL is continuously reading from and writing to the same set of files from multiple processes, it tends to trigger programming and design mistakes in antivirus software, particularly problems related to concurrency. Such problems can cause random and unpredictable errors, or even data corruption.

Antivirus software is also likely to dramatically slow down PostgreSQL's operation. For that reason, you should at least exclude postgres.exe and the data directories so the scanner ignores them.

===== What Anti-Virus software is compatible? =====

The systems used to build the Windows installers all run either Sophos AV or AVG Free Edition, and
those systems pass a full set of PostgreSQL regression tests running those programs.
Microsoft Security Essentials is also known to work.

Specific issues have been reported with the ''nod32'' antivirus
product. If you are using this product, add "postmaster.exe" to the list
of excluded processes (available under advanced options). This has been
reported to fix the problem.

Specific issues have also been reported with McAfee and Panda anti-virus
software and NetLimiter network monitoring software. While some people do have
PostgreSQL working with these software packages, there is no specific or even
recommend solutions that have not worked in some cases, so the issues would appear
to be installation specific, sometimes even requiring uninstallation.

==== Software firewalls ====

If you have any 3rd-party firewall software installed on your machine, try either disabling it or uninstalling it. There's really no need for 3rd party firewalls on Windows XP and above, as the built-in firewall provided by Microsoft does an excellent job already. Some badly-written 3rd party firewalls do not uninstall correctly, so after uninstallation you might have to [http://support.microsoft.com/kb/299357 tell Windows to repair its network settings].

If you had a 3rd-party firewall and have now uninstalled it, make sure to turn Windows Firewall back on, as many products turn it off during installation and fail to turn it back on during uninstallation.

==== The installer exits with a runtime installation error? ====

The installer may exit with an error like: ''An error occured executing the Microsoft VC++ runtime installer''. This can only happen on Windows.

There are two main reasons why this may occur:

1) The Windows Scripting Host is unable to execute VBscripts. This can occur if the scripting host is disabled (which is unusual), or if the installation is broken. A sign of this problem is a message like ''CScript Error: Can't find script engine "VBScript" for script "C:\...''. It can often be resolved by re-registering the VBscript interpreter - click ''Start'' -> ''Run'' and enter the following and click ''OK'':

regsvr32 %systemroot%\system32\vbscript.dll

If that fails, on older versions of Windows you can try [http://www.microsoft.com/downloads/en/results.aspx?freetext=windows+script+host&displaylang=en&stype=s_basic updating the scripting host].

Also, make sure that the registry value in HKEY_CLASSES_ROOT\.vbs\(Default) is VBSFile. [http://igordcard.blogspot.com/2012/03/unable-to-write-inside-temp-environment.html]

2) The installer is unable to properly read and write files to the system ''TEMP'' directory. This can occur if the ''TEMP'' or ''TMP'' environment variables are set to non-standard values, and can be recognised by errors in the logfile indicating that scripts could not be executed or found. To resolve this issue, ensure the ''TEMP'' and ''TMP'' variables are set to their correct values.

==== Trouble with passwords for the postgres user ====

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

==== PATH environment variable ====

There is also an issue if you have installed ''cygwin'', and the cygwin\bin directory is present
in the system PATH variable. There are DLL files in the cygwin directory related to interpreted languages (TCL,
perl, python) that contain bugs that can cause the installer or the installed version of PostgreSQL to either hang
or crash. Remove the cygwin\bin directory from your path before running the installer!

Problems have also been observed when the PATH environment variable contains directories containing versions of libssl and/or libintl.

==== I'm getting permissions errors when installing/running initdb ====

Make sure the PostgreSQL service account has permissions on the directories leading up to the one
you have installed into. The installer will set permissions on the install directory but not on
parent directories of it.

You may also see related errors show up as "The database Cluster initialisation failed" during the One Click installer.

Check your install-postgresql log
but it is usually related to permission errors. The following thread may help,

http://forums.enterprisedb.com/posts/list/2044.page#7503

Or alternatively, you can fix up the directory permissions and then manually restart the initcluster.vbs script like this for v9,

<pre>
cscript //NoLogo "<install_path>/installer/server/initcluster.vbs" "postgres" "postgres" "<password>" "<install_path>" "<data_path>" 5432 "DEFAULT"
</pre>

==== Check the %COMSPEC% environment variable ====

Some Windows installations seem to land up with an incorrect %COMSPEC% environment variable that prevents the execution of initdb.

In a command prompt, run:

<pre>
echo %COMSPEC%
</pre>

You should get something like:

C:\Windows\system32\cmd.exe

(Where C:\Windows is your Windows install location).

If you see something else, check the System control panel, and in the Environment section check for COMSPEC. If its value there is wrong:

* Make a system restore point; and
* Back up your computer; then
* Change it in the system environment settings, so it points to the correct location of cmd.exe

You can test to make sure it's right by:

* Opening a new cmd.exe prompt (not re-using one that was already open); and
* Running <code>"%COMSPEC%" /C "echo test ok"</code>

It should print "test ok".

==== The installer claims the specified account is an administrator, but it isn't! ====

Most likely, the specified account is an administrator or power user,
even though you aren't aware of it. The check used by the installer
specifically checks for membership in the Administrators or
Power Users group. Work your way backwards using Local Users and Groups -
open the Administrators group, see who's a member. Then check any
groups (domain or local) that are a member of the Administrators group,
and any groups members of that group etc. PostgreSQL checks any level
of nested groups.

==== I'm getting an error message that says PostgreSQL cannot be installed from a Terminal Services session ====

This is unfortunately so. The PostgreSQL backend won't run from a TS session, and in order to do initdb the installer
has to start a standalone backend. Therefore, installation has to be performed from the console. Note that if you are
using Windows Server 2003, you can get remote access to the actual console and not just an administrative session.
To do this, start the Remote Desktop Connection by executing mstsc /console, and then connect as usual.
This will lock the local console of the server and give you control over that session. In this scenario,
PostgreSQL should install just fine.

==== I get the error "the user has not been granted the requested logon type at this computer" or similar ====

Make sure the specified PostgreSQL account has the "Log on as a service"
and "Log on locally" rights. The "Log on locally" is only required for
the install part, and can be removed once the installation is completed
if security policies require it. (Rights are granted and revoked using
the "Local Security Policy" MMC snapin. "Log on locally" is default,
and "Log on as a service" will normally be granted automatically by
the installer).

If you still have this problem, enable auditing (also using
the "Local Security Policy" snapin) and let us know what other rights
were required in your setup.

Note that if your computer is a member of a domain, the settings of
the security policies may be controlled at the domain level using
Group Policy.

==== How do I delete the service account - it's not listed under users! ====

Windows sometimes hide some accounts from the GUI tools, so they cannot be removed from there. This includes
the auto-created service account for PostgreSQL (that may be left over from a previous installation). To delete this
account, use the NET command on the commandline:
NET USER <username> /DELETE
Where <username> is the windows login name of the user, for example ''postgres''.

== Common runtime issues ==

=== I'm getting "dynamic load error" when installing a procedural language ===

Most commonly this means that the actual language DLL for the procedural language is missing. The PostgreSQL
DLLs only contains the language bindings, and require the language distribution DLLs to be present
in the system PATH. For a list of the current required DLLs for the different procedural languages,
please see [http://pginstaller.projects.postgresql.org the installation instructions].

To find out exactly which DLL files are missing, you can use the ''depends'' tool from Microsoft.
It is available in the Windows Support Tools, that are on the Windows CD as a separate install. Just run
''depends plpython.dll'' (for PL/python) to show which imports are missing.

=== I'm seeing a lot of postgres.exe processes even though I only started the server once ===

This is normal. PostgreSQL uses a multi-process architecture. In an empty system you will see anything from two to
five processes. Once clients start to connect, the number of processes will increase.

=== How do I set an environment variable? ===

PostgreSQL uses environment variables for several settings. To change an environment variable in most
Windows versions, go into Properties for My Computer, then into Advanced. Note that there are two sets of
environment variables - one for the system which applies to all users and one for the current user. If you
want an environment variable to affect the PostgreSQL service, you must change the system variable. After
changing a system variable, you must restart the service.

=== I cannot run with more than about 125 connections at once, despite having capable hardware ===

When running as a service, you may experience failures with more than approximately 125 simultaneous connections.
This can happen because some of the libraries that PostgreSQL is dependent on are dependent on user32.dll which allocates
memory from an area known as the Desktop Heap. The desktop heap is assigned to each logon session, with non-interactive
sessions typically being assigned 512KB. Each postgres process that runs typically consumes approximately 3.2KB of desktop
heap, which coupled with other overhead can exhaust the allocated heap at somewhere around 125 connections. This doesn't
happen when running from the command line (or more precisely, happens with much higher numbers of connections) because the
interactive logon session is typically allocated 3MB of Desktop Heap.

You can increase the non-interactive Desktop Heap by modifying the third SharedSection value in the registry as described
in this [http://support.microsoft.com/kb/184802 Microsoft Knowledgebase article]. Note that this should be done
with great care as specifying a value that is excessively high may prevent your system from booting.

[[Category:FAQ]] [[Category:Windows]]

== Windows version-specific issues ==

==== Can I install a 32-bit PostgreSQL on 64-bit Windows? ====

Recent 32-bit versions of PostgreSQL (8.3 and newer) can be installed and used on 64-bit Windows XP and above,
though they retain the 32-bit limits on maximum process address space (and thus shared memory).

You can connect to the 32-bit postgresql server from 64-bit programs on the computer the server is running on
or other computers if a 64-bit libpq or psqlODBC driver is installed where the program is running.

Because 32-bit versions of the PostgreSQL server only install a 32-bit libpq and pgsqlODBC, only 32-bit programs
on the computer the server was installed on can use the database unless a 64-bit ODBC driver or libpq
is installed as an add-on.

==== Where is the PostgreSQL ODBC driver? I'm running 32-bit PostgreSQL on 64-bit Windows ====

You need to use the 32-bit ODBC administrator to set up data sources for 32-bit
applications using 32-bit drivers.

Unless you've also installed a [[#What about 64-bit ODBC drivers?|64-bit version]] of
[http://psqlodbc.projects.postgresql.org psqlODBC], a 32-bit install of PostgreSQL will
only have a 32-bit ODBC driver. The 32-bit ODBC driver may only be used by 32-bit programs,
and ''will not show up in the 64-bit ODBC administrator''.

This gets confusing because on 64-bit windows <code>c:\windows\system32\odbcad32</code> is the ''64-bit''
ODBC driver administrator, despite the name. This is a historical artifact of Windows development.
Apparently many apps and installers depend on odbcad32.exe having that name and path,
so Microsoft landed up being stuck with it despite the now-stupid name, which made sense back
in the 16- to 32-bit transition but makes none now. It's the same reason the
"system32" directory is still called that on 64-bit Windows. PostgreSQL can't do anything about this.

See: [http://support.microsoft.com/kb/942976 http://support.microsoft.com/kb/942976]

You'll see in that article that the 32-bit ODBC administrator on 64-bit Windows is:

<pre>
%systemdrive%\Windows\SysWoW64\odbcad32.exe
</pre>

You can launch this from "Start->Run" using the path above. You will see the PostgreSQL ODBC drivers in the
32-bit ODBC administrator.

You 'can not' use a 32-bit ODBC driver in a 64-bit application. That means that you'll still only be
able to use the PostgreSQL ODBC driver with 32-bit applications unless you install a 64-bit ODBC driver
as well.

==== Can I use a 64-bit ODBC program with a 32-bit PostgreSQL server? ====

Only if you have a 64-bit [http://psqlodbc.projects.pgfoundry.org/] driver installed. See the installation section.

YourPostgreSQLAddress

2013-08-20T19:00:43Z

Mastermind:

please see [https://wiki.postgresql.org/wiki/HowToUseYourPostgreSQLMailAccount | postgresql.org mailaccount details] for further information

YourPostgreSQLAddress

2013-08-20T18:59:12Z

Mastermind: Blanked the page

HowToUseYourPostgreSQLMailAccount

2013-08-20T18:58:06Z

Mastermind: fix the most obvious errors wrt the postgresql.org mail infrastructure

== Logging In/Account Creation ==

If you have never had an @postgresql.org account before, or for some reason
can't get into yours, please e-mail josh@postgresql.org for further details.

== Your Address ==

Your e-mail address will be the 2-letter ISO country code for your country,
followed by @postgresql.org. For example, Diogo has br@postgresql.org.
The exceptions to this are Devrim, who has devrim@postgresql.org due to his
work on the website, and Tatsuo/JPUG, who prefer to use their list address.

We will not be using people's personal addresses, because the @postgresql.org
addresses make possible an easy transition from one regional contact to
another. It also looks more professional.

== Appropriate Uses of Your @Postgresql.org address ==

Your @postgresql.org address is intended strictly for use when doing volunteer
advocacy for PostgreSQL.org. It is NOT intended for a general mailbox or
business address; remember, it may be assigned to someone else at any time
which you are unable to volunteer.

This can particularly be a challenge for consultants. My rule is, if you're
answering queries from @postgresql.org, you can recommend your own business
for consulting ... but you MUST mention other appropriate consultants in the
area as well. Nor should you take referral fees for business referred
through your @postgresql.org address. (Sorry if this seems pedantic, but
there have already been some misunderstandings.)

I will be forwarding e-mails received from the public to your @postgresql.org
address from time to time. This is much, much easier for me than keeping
track of personal addresses. As such, it's important that you continue to
check the address (see below) for the next year, or tell me when you are
stopping.

Also, please remember that you are not personally able to make decisions on
behalf of the whole PostgreSQL.org community. No-one is, not even the
members of Core Team. We are a democratic organization. I have to tell
reporters and business people that all the time.

== How to Access Your PostgreSQL.org Address ==

The postgresql.org mail system is accessible through various different interfaces, depending on how you want to use it you can choose between:

'''Webinterface:''' Go to [https://webmail.postgresql.org postgresql.org webmail system] and log in. This gets you into
RoundCube, a fairly simple webmail interface. It is even multi-lingual.

'''POP3/IMAP4:''' You can access imap.postgresql.org via POP3 or IMAP4 using the hostname imap.postgresql.org

'''SMTP:''' we provide an authenticated-only SMTP relay service using the hostname smtp.postgresql.org

=== Technical Usage guidelines ===

* use the full emailaddress (for example cl@postgresql.org) as your username
* we '''strongly''' recommend using transport layer security on all connections to our systems, that means please use https for the webmailinterface and enable STARTTLS for your SMTP and IMAP4 sessions
* the maximum size of a mail transmitted over SMTP is restricted to 20MB, there is currently no quota enforced for IMAP4/POP3 but we deserve the right to implement that if needed

FORWARDING: If you do not often get @postgresql.org e-mail (and few people
other than Brazillian and Spanish speakers will) it is suggested that you
Forward your @postgresql.org e-mail to another account. Do it this way:

# log into webmail.postgresql.org
# click on the "settings" icon
# choose "Filters"
# click the little gear and choose "standard editor"
# click the + for "new rule"
# select "all messages"
# select "redirect to"
# type in your email address
# click + for add another action
# choose "Discard"
# click "Save"
# test the new filter by sending mail to yourself

== Sharing Your @postgresql.org Account ==

Several regions, such as DE and FR, have more than one person sharing an account to
collaborate. There are two ways you can make this work:

* Use webmail/IMAP4. Which messages are replied to and what has been received will be obvious.
* Use forwarding rules: set up forwarding to multiple accounts, and treat the @postgresql address like it was a mailing list. Please do not add more than 2-3 forwarding destinations, if you feel you need more please ask for further details.

Talk:Main Page

2013-08-07T17:09:59Z

Mastermind: Reverted edits by Faseeh1218 (talk) to last revision by Dani_jayant

MediaWiki:Licenses

2013-06-16T16:08:20Z

Mastermind: add TPL

* The PostgreSQL Licence|The PostgreSQL Licence

Todo

2013-01-27T19:01:07Z

Mastermind:

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

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]].

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

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

For Developers: Unfortunately this list does not contain all the information necessary for someone to start coding a feature. Some of these items might have become unnecessary since they were added --- others might be desirable but the implementation might be unclear. When selecting items listed below, be prepared to first discuss the value of the feature. Do not assume that you can select one, code it and then expect it to be committed. Always discuss design on Hackers list before starting to code. The flow should be:

Desirability -> Design -> Implement -> Test -> Review -> Commit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{TodoItem
|Allow synchronous_standby_names to be disabled after communication failure with all synchronous standby servers exceeds some timeout
|This also requires successful execution of a synchronous notification command.
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00409.php
}}

{{TodoEndSubsection}}

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

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

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

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

{{TodoItem
|Allow per-tablespace quotas}}

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

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

{{TodoEndSubsection}}

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

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

{{TodoEndSubsection}}

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

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

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

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

{{TodoItem
|Allow base backup from standby to continue when the standby is promoted.
* [http://archives.postgresql.org/pgsql-hackers/2012-10/msg00239.php <nowiki>Re: Promoting a standby during base backup</nowiki>]
}}

{{TodoEndSubsection}}

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

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

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

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

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

{{TodoItemf
| Allow time-delayed application of logs on the standby
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00992.php
}}

{{TodoItem
| Add -X parameter to pg_basebackup to specify a different directory for px_xlog, like initdb
}}

{{TodoItem
| Add a new "eager" synchronous mode that starts out synchronous but reverts to asynchronous after a failure timeout period
|This would require some type of command to be executed to alert administrators of this change.
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg01224.php
}}

{{TodoEndSubsection}}

== Data Types ==

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

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

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

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

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

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

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

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

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

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

{{TodoItem
|Remove or improve rounding in geometric comparison operators
* http://archives.postgresql.org/message-id/9804.1346187849@sss.pgh.pa.us
}}

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

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

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

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

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

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

{{TodoEndSubsection}}

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

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

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

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

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

{{TodoEndSubsection}}

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

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

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

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

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{TodoEndSubsection}}

== Functions ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{TodoItem
|Add function to allow easier transaction id comparisons
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00786.php
}}

=== Character Formatting ===

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

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

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

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

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

{{TodoEndSubsection}}

== Multi-Language Support ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Views / Rules ==

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

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

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

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

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

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

== SQL Commands ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{TodoItem
|Allow PREPARE of cursors}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{TodoEndSubsection}}

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

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

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

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

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

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

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

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

{{TodoEndSubsection}}

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

{{TodoEndSubsection}}

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

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

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

{{TodoEndSubsection}}

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

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

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

{{TodoEndSubsection}}

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

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

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

{{TodoEndSubsection}}

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

{{TodoSubsection}}

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

{{TodoEndSubsection}}

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

{{TodoItem
|Add MATCH PARTIAL referential integrity}}

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

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

{{TodoItem
|Are ri_KeysEqual checks in the RI enforcement triggers still necessary?
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]
}}

{{TodoItemDone
|Optimize referential integrity checks involving null values
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php <nowiki>Can't ri_KeysEqual() consider two nulls as equal?</nowiki>]
}}

{{TodoEndSubsection}}

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

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

{{TodoEndSubsection}}

== Server-Side Languages ==

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

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

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

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

{{TodoItem
|Allow holdable cursors in SPI}}

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

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

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

{{TodoEndSubsection}}

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

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

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

{{TodoItem
|Allow row and record variables to be set to NULL constants, and allow NULL tests on such variables
|Because a row is not scalar, do not allow assignment from NULL-valued scalars.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]
}}

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

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

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

{{TodoEndSubsection}}

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

{{TodoEndSubsection}}

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

{{TodoItem
|Add table function support}}

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

{{TodoEndSubsection}}

== Clients ==

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

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

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

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

{{TodoItem
|Add additional shutdown modes, and change the default?
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg01283.php
}}

{{TodoEndSubsection}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{TodoItem
|Improve speed of tab completion by using LIKE
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org
}}

{{TodoEndSubsection}}

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

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

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

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

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

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

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

{{TodoItemDone
|Add support for multiple pg_restore -t options, like pg_dump}}

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

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

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

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

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

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

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

{{TodoItem
|Preserve sparse storage of large objects over dump/restore
* [http://archives.postgresql.org/message-id/18789.1349750451@sss.pgh.pa.us <nowiki>TODO item: teach pg_dump about sparsely-stored large objects</nowiki>]
}}

{{TodoEndSubsection}}

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

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

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

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

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

{{TodoItem
|Fix nested C comments}}

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

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

{{TodoItem
|Allow multidimensional arrays}}

{{TodoItem
|Implement COPY FROM STDIN}}

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

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

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

{{TodoEndSubsection}}

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

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

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

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

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

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

{{TodoEndSubsection}}

=== HTTP===
{{TodoSubsection}}

{{TodoItem
|Allow access to the database via HTTP
|See [[HTTP_API]]}}

{{TodoEndSubsection}}

== Triggers ==

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

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

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

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

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

{{TodoItemDone
|Add event triggers
}}

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

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

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

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

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

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

== Inheritance ==

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

{{TodoItem
|Honor UNIQUE INDEX on base column in INSERTs/UPDATEs on inherited table, e.g. INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
|The main difficulty with this item is the problem of creating an index that can span multiple tables.}}

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

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

== Indexes ==

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

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

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

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

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

{{TodoItem
|Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY
|This is difficult because you must upgrade to an exclusive table lock to replace the existing index file. CREATE INDEX CONCURRENTLY does not have this complication. This would allow index compaction without downtime.
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00911.php
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg00128.php
}}

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

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

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

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

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

{{TodoItem
|[http://archives.postgresql.org/pgsql-hackers/2012-05/msg00669.php Support amgettuple() in GIN (useful for exclusion constraints)]
}}

{{TodoItem
| Allow "loose" or "skip" scans on btree indexes in which the first column has low cardinality
* http://archives.postgresql.org/pgsql-performance/2012-08/msg00159.php
}}

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

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

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

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

{{TodoItem
|[http://archives.postgresql.org/message-id/4DC8D284-05CF-4E3D-9670-AC9A32C37A36@justatheory.com GiST index support for arrays]
}}

{{TodoEndSubsection}}

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

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

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

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

{{TodoEndSubsection}}

== Sorting ==

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

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

{{TodoItem
|Consider detoasting keys before sorting}}

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

== Fsync ==

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

{{TodoItem
|Consider sorting writes during checkpoint
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php <nowiki>Re: Sorting writes during checkpoint</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg02012.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00278.php
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00493.php
}}

== Cache Usage ==

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

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

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

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

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

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

{{TodoItem
|Improve cache lookup speed for sessions accessing many relations
* http://archives.postgresql.org/pgsql-hackers/2012-11/msg00356.php
}}

== Vacuum ==

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

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

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

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

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

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

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

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

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

{{TodoItem
|Vacuum Gin indexes in physically order rather than logical order
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg00443.php
}}

{{TodoItem
|Avoid creation of the free space map for small tables
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg01751.php
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00552.php
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00615.php
}}

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

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

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

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

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

{{TodoItem
|Allow visibility map all-visible bits to be set even when an auto-ANALYZE is running
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00356.php
}}

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

{{TodoItem
|Improve autovacuum tuning
* http://www.postgresql.org/message-id/5078AD6B.8060802@agliodbs.com
}}

{{TodoEndSubsection}}

== Locking ==

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

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

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

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

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

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

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

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

== Startup Time Improvements ==

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

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

== Write-Ahead Log ==

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

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

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

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

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

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

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

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

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

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

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

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

== Optimizer / Executor ==

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

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

{{TodoItem
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00597.php
}}

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

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

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

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

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

{{TodoItem
|Allow the CTE (Common Table Expression) optimization fence to be optionally disabled
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00700.php
* http://archives.postgresql.org/pgsql-performance/2012-11/msg00161.php
}}

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

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

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

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

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

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

{{TodoEndSubsection}}

== Background Writer ==

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

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

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

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

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

== Concurrent Use of Resources ==

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

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

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

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

== TOAST ==

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

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

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

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

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

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

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

{{TodoItem
| Add entry creation timestamp column to pg_stat_replication
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00694.php
}}

{{TodoItem
| Allow reporting of stalls due to wal_buffer wrap-around
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00826.php
}}

{{TodoItem
| Restructure pg_stat_database columns tup_returned and tup_fetched to return meaningful values
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org
}}

== Miscellaneous Performance ==

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

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

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

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

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

{{TodoItem
|Consider increasing the minimum allowed number of shared buffers
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]
}}

{{TodoItem
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]
}}

{{TodoItem
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]
}}

{{TodoItem
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]
}}

{{TodoItem
|Sort large UPDATE/DELETEs so it is done in heap order
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]
}}

{{TodoItem
|Consider decreasing the I/O caused by updating tuple hint bits
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php
}}

{{TodoItem
|Avoid the requirement of freezing pages that are infrequently modified
|If all rows on a page are visible, it is possible to set a bit in the visibility map (once the visibility map is 100% reliable) and not need to freeze the page, avoiding a page rewrite
* http://archives.postgresql.org/message-id/4BF701CF.2090205@agliodbs.com
* http://archives.postgresql.org/pgsql-hackers/2010-06/msg00082.php
}}

{{TodoItem
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]
}}

{{TodoItem
|Restructure truncation logic to be more resistant to failure
|This also involves not writing dirty buffers for a truncated or dropped relation
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php
}}

{{TodoItem
|Consider adding logic to increase large tables by more than 8k
|This would reduce file system fragmentation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00337.php
}}

== Miscellaneous Other ==

{{TodoItem
|Deal with encoding issues for filenames in the server filesystem
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}
}}

{{TodoItem
|Deal with encoding issues in the output of localeconv()
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]
}}

{{TodoItem
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg00846.php <nowiki>patch - Report the schema along table name in a referential failure error message</nowiki>]
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]
}}

{{TodoItemDone
| Provide [http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html#LIBPQ-CONNECT-FALLBACK-APPLICATION-NAME fallback_application_name] in contrib/pgbench, oid2name, and dblink.
* {{MessageLink|w2g9837222c1004070216u3bc46b3ahbddfdffdbfb46212@mail.gmail.com|fallback_application_name and pgbench}}
}}

{{TodoItem
|Add 64-bit support to /contrib/pgbench
* http://archives.postgresql.org/pgsql-hackers/2010-07/msg00153.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00705.php
}}

== Source Code ==

{{TodoItemEasy
|Remove warnings created by -Wcast-align}}

{{TodoItem
|Move platform-specific ps status display info from ps_status.c to ports}}

{{TodoItem
|Add optional CRC checksum to heap and index pages
|One difficulty is how to prevent hint bit changes from affecting the computed CRC checksum.
* http://archives.postgresql.org/message-id/19934.1226601952%40sss.pgh.pa.us
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00002.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01028.php <nowiki>double-buffering page writes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00524.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01101.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00011.php <nowiki>Re: Block-level CRC checks</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00249.php
* http://archives.postgresql.org/message-id/20111221215913.GA4536@fetter.org
* http://archives.postgresql.org/message-id/CA+U5nMJzQyxcObkpNAf1SYTX-gO_Mom3O9JXHnGpxRo1kXJ7ww@mail.gmail.com
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00128.php
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00113.php
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00172.php
* http://archives.postgresql.org/pgsql-hackers/2012-03/msg00001.php
* http://archives.postgresql.org/pgsql-hackers/2012-03/msg00188.php
}}

{{TodoItem
|Consider a faster CRC32 algorithm
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php
}}

{{TodoItem
|Allow cross-compiling by generating the zic database on the target system}}

{{TodoItem
|Improve NLS maintenance of libpgport messages linked onto applications}}

{{TodoItem
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}

{{TodoItem
|Allow creation of universal binaries for Darwin
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]
}}

{{TodoItem
|Consider GnuTLS if OpenSSL license becomes a problem
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]
}}

{{TodoItem
|Consider making NAMEDATALEN more configurable in future releases}}

{{TodoItem
|Research use of signals and sleep wake ups
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]
}}

{{TodoItem
|Allow C++ code to more easily access backend code
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]
}}

{{TodoItem
|Consider simplifying how memory context resets handle child contexts
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]
}}

{{TodoItem
|Create three versions of libpgport to simplify client code
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]
}}

{{TodoItem
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]
}}

{{TodoItem
|Implement the non-threaded Avahi service discovery protocol
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]
}}

{{TodoItem
|Reduce data row alignment requirements on some 64-bit systems
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]
}}

{{TodoItem
|Restructure TOAST internal storage format for greater flexibility
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]
}}

{{TodoItem
| Add regression tests for pg_dump/restore
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01967.php <nowiki>"make install-check-pg_dump" target in src/regress]</nowiki>]
}}

{{TodoItem
| Research different memory allocation methods for lists
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php
}}

{{TodoItem
| Consider removing the attribute options cache
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00039.php
}}

{{TodoItem
| Restructure /contrib section
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00705.php
}}

{{TodoItem
| Consider adding explicit huge page support
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00123.php
}}

=== /contrib/pg_upgrade ===
{{TodoSubsection}}

{{TodoItem
|Handle large object comments
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.
}}

{{TodoItem
|Consider using pg_depend for checking object usage in version.c
}}

{{TodoItem
|If reindex is necessary, allow it to be done in parallel with pg_dump custom format
}}

{{TodoItem
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary
|pg_class.oid is not preserved so schema.tablename must be used.
* [http://archives.postgresql.org/message-id/CAAZKuFaWdLkK8eozSAooZBets9y_mfo2HS6urPAKXEPbd-JLCA@mail.gmail.com pg_upgrade and statistics]
}}

{{TodoItem
|Improve testing, perhaps using the buildfarm
|The buildfarm has access to multiple versions of PostgreSQL.
}}

{{TodoItem
|Create machine-readable output of pg_controldata
|This would avoid parsing its output. The problem is we need pg_controldata output from both the old and new clusters so we would need to support both formats.
}}

{{TodoItem
|Find cleaner way to start/stop dedicated servers for upgrades
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00275.php
}}

{{TodoItem
|Consider a way to run pg_upgrade on standby servers
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00453.php
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00056.php
}}

{{TodoEndSubsection}}

=== Windows ===
{{TodoSubsection}}

{{TodoItem
|Remove configure.in check for link failure when cause is found}}

{{TodoItem
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}

{{TodoItem
|Allow psql to use readline once non-US code pages work with backslashes}}

{{TodoItem
|Fix problem with shared memory on the Win32 Terminal Server}}

{{TodoItem
|Improve signal handling
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]
}}

{{TodoItem
|Convert MSVC build system to remove most batch files
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]
}}

{{TodoItem
|Support pgxs when using MSVC}}

{{TodoItem
|Fix MSVC NLS support, like for to_char()
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php <nowiki>Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)</nowiki>]
}}

{{TodoItem
|Find a correct rint() substitute on Windows
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]
}}

{{TodoItem
|Fix global namespace issues when using multiple terminal server sessions
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}

{{TodoItem
|Change from the current autoconf/gmake build system to cmake
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01869.php <nowiki>About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)</nowiki>]
}}

{{TodoItem
|Improve consistency of path separator usage
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net
}}

{{TodoItem
|Fix cross-compiling on Windows
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php
}}

{{TodoItem
|Reduce file statistics overhead on directory reads
* http://www.postgresql.org/message-id/1338325561.82125.YahooMailNeo@web39304.mail.mud.yahoo.com
}}

{{TodoEndSubsection}}

=== Wire Protocol Changes ===
{{TodoSubsection}}

{{TodoItem
|Allow dynamic character set handling}}

{{TodoItem
|Add decoded type, length, precision}}

{{TodoItem
|Mark result columns as known-not-null when possible
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]
}}

{{TodoItem
|Provide more control over planner treatment of statements being prepared}}

{{TodoItem
|Use compression
|If SSL is used, hopefully avoid the overhead of key negotiation and encryption
* http://archives.postgresql.org/pgsql-hackers/2012-06/msg00793.php
}}

{{TodoItem
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}

{{TodoItem
|Set protocol for wire format negotiation
* [http://archives.postgresql.org/message-id/CACMqXCKkGrGXxQhjHCKCe0B8hn6sTt-1sdgHZOSGQMxrusOsQA@mail.gmail.com GUC_REPORT for protocol tunables]
}}

{{TodoItem
|Make sure upgrading to a 4.1 protocol version will actually work smoothly
* [http://archives.postgresql.org/message-id/28307.1318255008@sss.pgh.pa.us Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable]
}}

{{TodoEndSubsection}}

== Documentation ==

{{TodoItemEasy
| Add contrib functions to the index
* 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]
}}

{{TodoItem
|Convert single quotes to apostrophes in the PDF documentation
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]
}}

{{TodoItem
|Provide a manpage for postgresql.conf
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Consider changing documentation format from SGML to XML
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]
* http://archives.postgresql.org/pgsql-docs/2011-04/msg00020.php
* http://wiki.postgresql.org/wiki/Switching_PostgreSQL_documentation_from_SGML_to_XML
}}

{{TodoItem
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com
}}

{{TodoItem
|Add diagrams to the documentation
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php
}}

== Exotic Features ==

{{TodoItem
|Add pre-parsing phase that converts non-ISO syntax to supported syntax
|This could allow SQL written for other databases to run without modification.}}

{{TodoItem
|Allow plug-in modules to emulate features from other databases}}

{{TodoItem
|Add features of Oracle-style packages
|A package would be a schema with session-local variables, public/private functions, and initialization functions. It is also possible to implement these capabilities in any schema and not use a separate "packages" syntax at all.
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]
}}

{{TodoItem
|Consider allowing control of upper/lower case folding of unquoted identifiers
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00849.php <nowiki>TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
}}

{{TodoItem
|Add autonomous transactions
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]
}}

{{TodoItem
|Give query progress indication
* [[Query progress indication]]
}}

{{TodoItem
|Rethink our type system
* [[Rethinking datatypes]]
}}

== Features We Do ''Not'' Want ==

The following features have been discussed ad nauseum on the PostgreSQL mailing lists and the consensus has been that the project is not interested in them. As such, if you are going to bring them up as potential features, you will want to be familiar with all of the arguments against these features which have been previously made over the years. If you decide to work on such features anyway, you should be aware that you face a higher-than-normal barrier to get the Project to accept them.

{{TodoItem
|All backends running as threads in a single process (not wanted)
|This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. Threading specific operations such as I/O, seq scans, and connection management has been discussed and will probably be implemented to enable specific performance features. Moving to a threaded engine would also require halting all other work on PostgreSQL for one to two years.}}

{{TodoItem
|"Oracle-style" optimizer hints (not wanted)
|Optimizer hints, as implemented in Oracle and other RDBMSes, are used to work around problems in the optimizer and introduce upgrade and maintenance issues. We would rather have such problems reported and fixed. We have discussed a more sophisticated system of per-class cost adjustment instead, but a specification remains to be developed. See [[OptimizerHintsDiscussion|Optimizer Hints Discussion]] for further information.}}

{{TodoItem
|Embedded server (not wanted)
|While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliably and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases. Besides, there are several very mature embedded SQL databases already available.}}

{{TodoItem
|Obfuscated function source code (not wanted)
|Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]
}}

{{TodoItem
|Indeterminate behavior for the GROUP BY clause (not wanted)
|At least one other database product allows specification of a subset of the result columns which GROUP BY would need to be able to provide predictable results; the server is free to return any value from the group. This is not viewed as a desirable feature. PostgreSQL 9.1 allows result columns that are not referenced by GROUP BY if a primary key for the same table is referenced in GROUP BY.
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]
}}

</div>

[[Category:Todo]]

PGDay FOSDEM 2013

2013-01-07T19:21:47Z

Mastermind: /* Dinner */

= PGDay FOSDEM 2013 =

This is the first PgDay we hold in Belgium. FOSDEM PGDay 2013 will be held on Feb 1st in Brussels, Belgium, at the Radisson Blu Royal hotel. As an extension to the regular PostgreSQL devroom at FOSDEM, it will cover topics for PostgreSQL users, developers and contributors, and anybody else interested in PostgreSQL

== Details ==

* '''Date:''' Feb 01st, 2013 9am-5pm
* '''Venue:''': Radisson Blu Royal Hotel
* '''Coordinator:''': PostgreSQL Europe [mailto:contact@pgconf.eu contact@pgconf.eu]
* '''Website:''': http://fosdem2013.pgconf.eu/

== Registration ==

Free attendance, web registration required: http://fosdem2013.pgconf.eu/registration/ (limited seats)

== Schedule ==

Schedule is be published at: http://fosdem2013.pgconf.eu/schedule/

== Location and Venue ==

http://fosdem2013.pgconf.eu/venue/

Address:

http://www.radissonblu.com/royalhotel-brussels/location

== Dinner ==

We are organizing a dinner after the event on Friday 1st, 2013 at Hard Rock Cafe Brussels. We have limited (30) number of seats, so please add your name to this list before going there.

If you are bringing someone to the event, make sure you enter your name *twice* (or more) on the list, so the attendee count matches!

Attendees:

# Devrim Gündüz
# Devrim Gündüz +1
# Magnus Hagander
# Andreas Scherbaum
# Andreas Scherbaum +1
# Jean-Paul Argudo
# Patryk Kordylewski
# Patryk Kordylewski +1
# Dimitri Fontaine
# Julien Rouhaud
# Dave Page
# Marc Cousin
# Stéphane Schildknecht
# Stéphane Schildknecht +1
# Jehan-Guillaume de Rorthais
# Guillaume Lelarge
# Markus Winand
# Marc Balmer
# Marc Balmer +1
# Stefan Kaltenbrunner

[[Category:PostgreSQL Events]]

Infrastructure team

2013-01-02T18:01:05Z

Mastermind: add sfrost

== Infrastructure Team ==

The Infrastructure team is responsible for running all of the postgresql.org infrastructure. This includes a wide variety of public and non-public services. PostgreSQL website development is discussed on the [http://archives.postgresql.org/pgsql-www/ pgsql-www mailing list]. Source code for the postgresql.org web site is stored in a public GIT repository, and is available on [http://git.postgresql.org/gitweb/?p=pgweb.git;a=summary]

== Infrastructure Team Members ==

The following people are part of the sysadmin team running the postgresql.org infrastructure. Note that not all of those people do have root-level access on all servers.

* Joshua Drake
* Marc Fournier
* Stephen Frost
* Magnus Hagander
* Álvaro Herrera
* Stefan Kaltenbrunner
* Greg Sabino Mullane
* Dave Page
* Robert Treat

[[Category:Community]]

Infrastructure team

2012-08-18T19:39:07Z

Mastermind: we have been on GIT for ages now

== Infrastructure Team ==

The Infrastructure team is responsible for running all of the postgresql.org infrastructure. This includes a wide variety of public and non-public services. PostgreSQL website development is discussed on the [http://archives.postgresql.org/pgsql-www/ pgsql-www mailing list]. Source code for the postgresql.org web site is stored in a public GIT repository, and is available on [http://git.postgresql.org/gitweb/?p=pgweb.git;a=summary]

== Infrastructure Team Members ==

The following people are part of the sysadmin team running the postgresql.org infrastructure. Note that not all of those people do have root-level access on all servers.

* Joshua Drake
* Marc Fournier
* Magnus Hagander
* Álvaro Herrera
* Stefan Kaltenbrunner
* Greg Sabino Mullane
* Dave Page
* Robert Treat

[[Category:Community]]

FAQ/de

2011-12-06T18:43:11Z

Mastermind: correct url

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

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

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

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

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:41:51Z

Mastermind: /* Welche Replikationslösungen gibt es? */

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

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

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

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

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:41:26Z

Mastermind: /* Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? */

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

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

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

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

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:41:05Z

Mastermind: /* Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? */

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

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

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

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

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html| COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:40:28Z

Mastermind: /* Hat PostgreSQL eine grafische Benutzerschnittstelle? */

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

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

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

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

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm| Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html| COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:40:07Z

Mastermind: more markup fixes

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

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

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

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

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools| Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm| Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html| COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:38:43Z

Mastermind: another markup fix

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

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

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

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

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr|PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr|PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools| Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm| Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html| COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:37:44Z

Mastermind: correct markup to make the links working

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

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

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

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

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning| Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr|PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr|PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools| Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm| Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html| COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

PostgreSQL Conference Europe Talks 2011

2011-10-19T16:18:35Z

Mastermind: add datacenter slide

= PostgreSQL Conference Europe 2011 Talks =

== Talks: Wednesday 18th October, 2011 ==

=== Ams 1 ===
* [[Media:Mohan_PGCon_Keynote_10-19-2011.pdf|Ram Mohan Keynote: Afilias Winning Bet on Open Source]]
* [http://www.oslandia.com/files/1646fd60f9b0a4558d1e256cf3264572/pgconfeu2011_vincent_picavet_postgis.pdf Vincent Picavet - Geo in your database : Postgis]
* [http://pgeu-plv8.herokuapp.com Will Leinweber: heralding the death of nosql]

=== Ams 2 ===

* [http://ora2pg.darold.net/ora2pg-best-practices.pdf Gilles Darold: Best practices with Ora2Pg]

=== Ams 3 ===

* [[Media:Ciolli-window-2011.pdf|Gianni Ciolli, Look Out The Window Functions (and free your SQL)]]
plus four 2D heat diffusion movies, with different starting scenarios: [[http://vimeo.com/30797130 a hot point]],
[[http://vimeo.com/30797509 a hot segment]],
[[http://vimeo.com/30797715 a hot square]] and
[[http://vimeo.com/30797797 a cold square]].
* [[Media:Smartgrid_for_the_datacenter_web.pdf|Stefan Kaltenbrunner, A smartgrid for the datacenter]]

== Talks: Thursday 19th October, 2011 ==

=== Ams 1 ===

=== Ams 2 ===

=== Ams 3 ===

== Talks: Friday 20th October, 2011 ==

=== Ams 1 ===

=== Ams 2 ===

=== Ams 3 ===

File:Smartgrid for the datacenter web.pdf

2011-10-19T16:16:45Z

Mastermind: A smartgrid for the datacenter

A smartgrid for the datacenter

PostgreSQL Release Support Policy

2011-10-01T19:39:09Z

Mastermind: mark the whole rows in italics for EOL'd releases to make the table a bit more readable

The PostgreSQL project aims to fully support a major release for '''five years''', under the terms of the [http://www.postgresql.org/support/versioning Versioning policy]

After a release falls out of full support, we may (at our committers' discretion) continue to apply further critical fixes to the source code, on a best-effort basis. No formal releases or binary packages will be produced by the project, but the updated source code will be available from our source code control system.

This policy will be followed on a best-effort basis. In extreme cases it may not be possible to support a release for the planned lifetime; for example if a serious bug is found that cannot be resolved in a given major version without significant risk to the stability of the code or loss of application compatibility. In such cases, early retirement of a major version may be required.

The first version update released after the EOL date will normally be the final one for that version. Note that this can extend support shortly past the listed date. For example, [http://www.postgresql.org/docs/7.4/static/release.html 7.4.30] and [http://www.postgresql.org/docs/8.0/static/release.html 8.0.26] were the EOL releases for those two versions. They were originally targeted for EOL as of July 2010, but those final versions were not actually released until October 2010.

=== End Of Life (EOL) dates ===

Releases which have already reached an EOL release are italicized:

{| cellspacing="0" cellpadding="5" border="1"
!Version
!EOL Date
!Release Date
|-
|''PostgreSQL 7.4''
|''October 2010 (extended)''
|''November 2003''
|-
|''PostgreSQL 8.0''
|''October 2010 (extended)''
|''January 2005''
|-
|''PostgreSQL 8.1''
|''November 2010''
|''November 2005''
|-
|PostgreSQL 8.2
|December 2011
|December 2006
|-
|PostgreSQL 8.3
|February 2013
|February 2008
|-
|PostgreSQL 8.4
|July 2014
|July 2009
|-
|PostgreSQL 9.0
|September 2015
|September 2010
|-
|PostgreSQL 9.1
|September 2016
|September 2011
|}