https://wiki.postgresql.org/api.php?action=feedcontributions&user=Martin.pihlak&feedformat=atomPostgreSQL wiki - User contributions [en]2024-03-29T07:55:35ZUser contributionsMediaWiki 1.35.13https://wiki.postgresql.org/index.php?title=File:Postgresql-at-skype.pdf&diff=28586File:Postgresql-at-skype.pdf2016-11-09T11:50:28Z<p>Martin.pihlak: </p>
<hr />
<div></div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=PostgreSQL_Conference_Europe_Talks_2016&diff=28585PostgreSQL Conference Europe Talks 20162016-11-09T11:47:17Z<p>Martin.pihlak: </p>
<hr />
<div>pgconf.eu 2016 took place in Tallinn, Estonia, from 2016-11-01 to 2016-11-04.<br />
<br />
== Tuesday (Trainings) ==<br />
<br />
{| class="wikitable"<br />
|Time||Room||Trainer||Title (Link to slides)<br />
|+<br />
| 09:00 - 17:00 || Alfa 2 || Petr Jelinek, Simon Riggs || PostgreSQL Replication & Upgrades<br />
|}<br />
<br />
== Wednesday ==<br />
<br />
{| class="wikitable"<br />
|Time||Room||Speaker||Title (Link to slides)<br />
|+<br />
| 09:30 - 10:20 || Alfa 2 || Devrim Gündüz || [https://www.gunduz.org/download.php?dlid=219 PostgreSQL Upgrades: Why and How?]<br />
|-<br />
| 11:10 - 12:00 || Alfa 2 || David Steele || [https://github.com/dwsteele/conference/blob/release/PostgresPatchReview-PGConfEU-2016/slides/slides.pdf Reviewing PostgreSQL Patches for Fun and Profit]<br />
|-<br />
| 11:10 - 12:00 || Omega || Chinh Nguyen, Neeran Gul || [[Media:Nguyen and Gul - PGConf.EU 2016.pdf|PostgreSQL in production at Yammer]]<br />
|-<br />
| 14:00 - 14:50 || Alfa 2 || Federico Campoli || [http://www.slideshare.net/FedericoCampoli/life-on-arollercoaster Life on a rollercoaster]<br />
|-<br />
| 14:00 - 14:50 || Omega || Alexander Korotkov || [http://www.slideshare.net/AlexanderKorotkov/the-future-is-csn The future is CSN]<br />
|-<br />
| 15:00 - 15:50 || Alfa 2 || Andreas Seltenreich || [https://korte.credativ.com/~ase/sqlsmith-talk.pdf Hunting PostgreSQL bugs with SQLsmith]<br />
|-<br />
| 16:20 - 17:10 || Alfa 2 || Jehan-Guillaume (ioguix) de Rorthais || [http://www.dalibo.org/_media/2016-pgconfeu-paf.html.gz PAF: auto failover and more!]<br />
|-<br />
| 17:20 - 18:10 || Alfa 2 || Emre Hasegeli || [http://www.slideshare.net/EmreHasegeli/managing-thousands-of-databases Managing Thousands of Databases]<br />
|}<br />
<br />
== Thursday ==<br />
<br />
{| class="wikitable"<br />
|Time||Room||Speaker||Title (Link to slides)<br />
|-<br />
| 11:50 - 12:40 || Alfa 2 || Giuseppe Broccolo & Julien Rouhaud || [http://www.dalibo.org/_media/gbroccolo_jrouhaud_pgconfeu2016_brin4postgis.pdf BRIN indexes on geospatial databases]<br />
|+<br />
| 12:50 - 13:40 || Alfa 1 || Markus Winand || [http://modern-sql.com/slides Modern SQL in open source and commercial databases]<br />
|+<br />
| 12:50 - 13:40 || Alfa 2 || Honza Horak || [[Media:161031_pgconf_databases_containers.pdf|Database Containers Made by Distributions]]<br />
|+<br />
| 14:40 - 15:30 || Omega || Alexey Papulovskiy || [http://papulovskiy.github.io/pgconfeu2016/ A billion rows pet-project on a desktop hardware]<br />
|+<br />
| 15:40 - 16:30 || Alfa 2 || Cédric Villemain || [[Media:2ndQUadrant Datastore xa.pdf|Transactions across multiple datastores]]<br />
|+<br />
| 15:40 - 16:30 || Omega || Khushboo Vashi || [[Media:Why_pgAdmin_4%3F.pdf|Why pgAdmin 4?]]<br />
|}<br />
<br />
== Friday ==<br />
<br />
{| class="wikitable"<br />
|Time||Room||Speaker||Title (Link to slides)<br />
|+<br />
| 09:30 - 10:20 || Omega || Oleg Bartunov, Artur Zakirov || [http://www.slideshare.net/ArthurZakirov1/better-full-text-search-in-postgresql Better Full Text Search in PostgreSQL]<br />
|-<br />
| 10:50 - 11:40 || Alfa 2 || Vik Fearing || [[:File:Lateral_tallinn.pdf|How Did We Live Without LATERAL?]]<br />
|-<br />
| 11:50 - 12:40 || Alfa 1 || David Steele || [https://github.com/dwsteele/conference/blob/release/AuditLogging-PGConfEU-2016/slides.pdf Audit Logging for PostgreSQL]<br />
|-<br />
| 11:50 - 12:40 || Alfa 2 || Alexey Lesovsky || [http://www.slideshare.net/alexeylesovsky/manage-postgresql-with-pgcenter Managing PostgreSQL with pgCenter]<br />
|-<br />
| 10:50 - 11:40 || Omega || Martin Pihlak || [[Media:postgresql-at-skype.pdf|PostgreSQL@Skype / The Untold]]<br />
|-<br />
| 13:40 - 14:30 || Omega || Cédric Villemain || [[Media:2ndQuadrant Stats talk.pdf|A close look at stats: what you can do with them !]]<br />
|-<br />
| 13:40 - 14:30 || Alfa 2 || Gülçin Yıldırım || [http://slides.com/apatheticmagpie/ft-in-postgres Evolution of Fault Tolerance in PostgreSQL]<br />
|}</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=PostgreSQL_Conference_Europe_Talks_2016&diff=28584PostgreSQL Conference Europe Talks 20162016-11-09T11:46:06Z<p>Martin.pihlak: </p>
<hr />
<div>pgconf.eu 2016 took place in Tallinn, Estonia, from 2016-11-01 to 2016-11-04.<br />
<br />
== Tuesday (Trainings) ==<br />
<br />
{| class="wikitable"<br />
|Time||Room||Trainer||Title (Link to slides)<br />
|+<br />
| 09:00 - 17:00 || Alfa 2 || Petr Jelinek, Simon Riggs || PostgreSQL Replication & Upgrades<br />
|}<br />
<br />
== Wednesday ==<br />
<br />
{| class="wikitable"<br />
|Time||Room||Speaker||Title (Link to slides)<br />
|+<br />
| 09:30 - 10:20 || Alfa 2 || Devrim Gündüz || [https://www.gunduz.org/download.php?dlid=219 PostgreSQL Upgrades: Why and How?]<br />
|-<br />
| 11:10 - 12:00 || Alfa 2 || David Steele || [https://github.com/dwsteele/conference/blob/release/PostgresPatchReview-PGConfEU-2016/slides/slides.pdf Reviewing PostgreSQL Patches for Fun and Profit]<br />
|-<br />
| 11:10 - 12:00 || Omega || Chinh Nguyen, Neeran Gul || [[Media:Nguyen and Gul - PGConf.EU 2016.pdf|PostgreSQL in production at Yammer]]<br />
|-<br />
| 14:00 - 14:50 || Alfa 2 || Federico Campoli || [http://www.slideshare.net/FedericoCampoli/life-on-arollercoaster Life on a rollercoaster]<br />
|-<br />
| 14:00 - 14:50 || Omega || Alexander Korotkov || [http://www.slideshare.net/AlexanderKorotkov/the-future-is-csn The future is CSN]<br />
|-<br />
| 15:00 - 15:50 || Alfa 2 || Andreas Seltenreich || [https://korte.credativ.com/~ase/sqlsmith-talk.pdf Hunting PostgreSQL bugs with SQLsmith]<br />
|-<br />
| 16:20 - 17:10 || Alfa 2 || Jehan-Guillaume (ioguix) de Rorthais || [http://www.dalibo.org/_media/2016-pgconfeu-paf.html.gz PAF: auto failover and more!]<br />
|-<br />
| 17:20 - 18:10 || Alfa 2 || Emre Hasegeli || [http://www.slideshare.net/EmreHasegeli/managing-thousands-of-databases Managing Thousands of Databases]<br />
|}<br />
<br />
== Thursday ==<br />
<br />
{| class="wikitable"<br />
|Time||Room||Speaker||Title (Link to slides)<br />
|-<br />
| 11:50 - 12:40 || Alfa 2 || Giuseppe Broccolo & Julien Rouhaud || [http://www.dalibo.org/_media/gbroccolo_jrouhaud_pgconfeu2016_brin4postgis.pdf BRIN indexes on geospatial databases]<br />
|+<br />
| 12:50 - 13:40 || Alfa 1 || Markus Winand || [http://modern-sql.com/slides Modern SQL in open source and commercial databases]<br />
|+<br />
| 12:50 - 13:40 || Alfa 2 || Honza Horak || [[Media:161031_pgconf_databases_containers.pdf|Database Containers Made by Distributions]]<br />
|+<br />
| 14:40 - 15:30 || Omega || Alexey Papulovskiy || [http://papulovskiy.github.io/pgconfeu2016/ A billion rows pet-project on a desktop hardware]<br />
|+<br />
| 15:40 - 16:30 || Alfa 2 || Cédric Villemain || [[Media:2ndQUadrant Datastore xa.pdf|Transactions across multiple datastores]]<br />
|+<br />
| 15:40 - 16:30 || Omega || Khushboo Vashi || [[Media:Why_pgAdmin_4%3F.pdf|Why pgAdmin 4?]]<br />
|}<br />
<br />
== Friday ==<br />
<br />
{| class="wikitable"<br />
|Time||Room||Speaker||Title (Link to slides)<br />
|+<br />
| 09:30 - 10:20 || Omega || Oleg Bartunov, Artur Zakirov || [http://www.slideshare.net/ArthurZakirov1/better-full-text-search-in-postgresql Better Full Text Search in PostgreSQL]<br />
|-<br />
| 10:50 - 11:40 || Alfa 2 || Vik Fearing || [[:File:Lateral_tallinn.pdf|How Did We Live Without LATERAL?]]<br />
|-<br />
| 11:50 - 12:40 || Alfa 1 || David Steele || [https://github.com/dwsteele/conference/blob/release/AuditLogging-PGConfEU-2016/slides.pdf Audit Logging for PostgreSQL]<br />
|-<br />
| 11:50 - 12:40 || Alfa 2 || Alexey Lesovsky || [http://www.slideshare.net/alexeylesovsky/manage-postgresql-with-pgcenter Managing PostgreSQL with pgCenter]<br />
|-<br />
| 10:50 - 11:40 || Omega || Martin Pihlak || [[:File:postgresql-at-skype.pdf|PostgreSQL@Skype / The Untold]]<br />
|-<br />
| 13:40 - 14:30 || Omega || Cédric Villemain || [[Media:2ndQuadrant Stats talk.pdf|A close look at stats: what you can do with them !]]<br />
|-<br />
| 13:40 - 14:30 || Alfa 2 || Gülçin Yıldırım || [http://slides.com/apatheticmagpie/ft-in-postgres Evolution of Fault Tolerance in PostgreSQL]<br />
|}</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=Replication,_Clustering,_and_Connection_Pooling&diff=8769Replication, Clustering, and Connection Pooling2009-11-19T04:09:04Z<p>Martin.pihlak: /* Comparison matrix */</p>
<hr />
<div>==Introduction==<br />
There are many approaches available to scale PostgreSQL beyond running on a single server. An outline of the terminology and basic technologies involved is at [http://www.postgresql.org/docs/current/interactive/high-availability.html High Availability and Load Balancing]. There is a [http://momjian.us/main/writings/pgsql/replication.pdf presentation] covering some of these solutions.<br />
<br />
There is no one-size fits all replication software. You have to understand your requirements and how various approaches fit into that. For example, here are two extremes in the replication problem space:<br />
<br />
* You have a few servers connected to a local network you want to always keep current for failover and load-balancing purposes. Here you would be considering solutions that are synchronous, eager, and therefore conflict-free.<br />
* Your users take a local copy of the database with them on laptops when they leave the office, make changes while they are away, and need to merge those with the main database when they return. Here you'd want an asynchronous, lazy replication approach, and will be forced to consider how to handle conflicts in cases where the same record has been modified both on the master server and on a local copy.<br />
<br />
These are both database replication problems, but the best way to solve them is very different. And as you can see from these examples, replication has a lot of specific terminology that you'll have to understand to figure out what class of solution makes sense for your requirements. A great source for this background is in the<br />
[http://www.postgres-r.org/documentation/terms Postgres-R Terms and Definitions for Database Replication]. The main theoretical topic it doesn't mention is how to resolve conflict resolution in lazy replication cases like the laptop situation, which involves voting and similar schemes.<br />
<br />
==Features in the Core of PostgreSQL==<br />
The PostgreSQL core team considered replication and clustering technology outside the scope of the main project's focus but this changed in Spring 2008, see the [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php Core Team's statement].<br />
<br />
*[[Warm Standby]]/Log Shipping is a HA solution which 'replicates' a database cluster to an archive or a warm (can be brought up quickly, but not available for querying) standby server. Overhead is very low and it's easy to set up. This is the simplest and best solution if all you care about is continuous backup and short failover times.<br />
<br />
*There's an ongoing project to integrate hot standby capabilites (read only queries on slave) into PostgreSQL...if/when complete, this would provide a replication mechanism similar to, but significantly better than mysql binary log replication, and would provide an excellent complement to slony. See [[Hot Standby]].<br />
<br />
==Comparison matrix==<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 100%; table-layout: fixed;"<br />
|- style="background: #ececec"<br />
! Program<br />
! License<br />
! Maturity<br />
! Replication Method<br />
! Sync<br />
! Connection Pooling<br />
! Load Balancing<br />
! Query Partitioning<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://www.pgcluster.org/ PGCluster]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | See version details on site<br />
| bgcolor="#ffffaa" | Master-Master<br />
| bgcolor="#ffffaa" | Synchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ddffdd" | Yes<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | '''pgpool-I'''<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Stable<br />
| bgcolor="#ffffaa" | Statement-Based Middleware<br />
| bgcolor="#ffffaa" | Synchronous<br />
| bgcolor="#ddffdd" | Yes<br />
| bgcolor="#ddffdd" | Yes<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://pgpool.projects.postgresql.org/ pgpool-II]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Recent release<br />
| bgcolor="#ffffaa" | Statement-Based Middleware<br />
| bgcolor="#ffffaa" | Synchronous<br />
| bgcolor="#ddffdd" | Yes<br />
| bgcolor="#ddffdd" | Yes<br />
| bgcolor="#ddffdd" | Yes<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://slony.info/ slony-I]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Stable<br />
| bgcolor="#ffffaa" | Master-Slave<br />
| bgcolor="#ffffaa" | Asynchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://bucardo.org/ Bucardo]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Stable<br />
| bgcolor="#ffffaa" | Master-Master, Master-Slave<br />
| bgcolor="#ffffaa" | Asynchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://wiki.postgresql.org/wiki/Skytools Londiste]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Stable<br />
| bgcolor="#ffffaa" | Master-Slave<br />
| bgcolor="#ffffaa" | Asynchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://www.commandprompt.com/products/mammothreplicator/ Mammoth]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Stable<br />
| bgcolor="#ffffaa" | Master-Slave<br />
| bgcolor="#ffffaa" | Asynchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://www.rubyrep.org/ rubyrep]<br />
| bgcolor="#ffffaa" | MIT<br />
| bgcolor="#ffffaa" | Recent Release<br />
| bgcolor="#ffffaa" | Master-Master, Master-Slave<br />
| bgcolor="#ffffaa" | Asynchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
|}<br />
<br />
==Replication==<br />
<br />
Aside from Warm Standby, mentioned above...<br />
<br />
*Slony-I: Seems good, single master only, master is a single point of failure, no good failover system for electing a new master or having a failed master rejoin the cluster. Slave databases are mostly for safety or for parallelizing queries for performance. Suffers from O(N^2) communications (N = cluster size). with reasonable sysadmin you can implement failover system yourself. regarding communications, you can cascade the replication to reduce load on the master. If you were implementing a large replication cluster, this would probably be a good idea. Slony is powerful, trigger based, and highly configurable.<br />
<br />
* PGCluster: PGCluster (which, incidentally, is not the same as PGCluster-II, a shared-disk solution), which does synchronous multimaster replication. Two single-points failure spots, load balancer and the data replicator. The project has historically looked a bit dead, but they just released a new version and moved to a Trac-based web site at http://www.pgcluster.org/ and http://pgfoundry.org/projects/pgcluster is up to date (at least downloads page) One major downside to PGCluster is that it uses a modified version of PostgreSQL, and it usually lags a few releases behind.<br />
<br />
* http://pgpool.projects.postgresql.org/ pgpool 1/2 is a reasonable solution. it's statement level replication, which has some downsides, but is good for certain things. pgpool 2 has a neat distributed table mechanism which is interesting. You might want to be looking here if you have extremely high ratios of read to write but need to service a huge transaction volume. Supports load-balancing and replication by implementing a proxy that duplicates all updates to all slaves. It can partition data by doing this, and it can semi-intelligently route queries to the appropriate servers.<br />
<br />
* "Mammoth Replicator" - BSD - http://www.commandprompt.com/products/mammothreplicator/ - Former proprietary solution, now open source. Uses a central logging process to distribute data changes amongst nodes. Essentially a fork of Postgres, as the changes are written directly into the backend. <br />
<br />
* "Bucardo" - BSD License - http://bucardo.org/ - Trigger-based, asynchronous, multi-master or master-slave, written using plperl.<br />
<br />
* Cybertec, an Austrian company, offers a proprietary packaging of PGCluster. They simply call it PostgreSQL Multimaster-Replication, see http://www.cybertec.at.<br />
<br />
* [[Londiste_Tutorial|Londiste]], a part of [[Skytools]] (https://developer.skype.com/SkypeGarage/DbProjects/SkyTools) which is a collection of replication tools from the Skype people. Purports to be simpler to use than Slony.<br />
<br />
* [http://www.continuent.com/index.php?option=com_content&task=view&id=212&Itemid=169 Continuent uni/cluster], proprietary and the related Sequoia (jdbc, formerly known as c-jdbc)<br />
<br />
* [http://www.postgres-r.org Postgres-R] is still in development. It features eager and thus conflict-free, but async multi-master replication.<br />
<br />
* DRBD (http://www.drbd.org/), a device driver that replicates disk blocks to other nodes. This works for failover only, not for scaling reads. Easy migration of devices if combined with an NFS export.<br />
<br />
* "Daffodil Replicator" - GPL - http://sourceforge.net/projects/daffodilreplica/ <br />
<br />
* "RubyRep" - MIT License - http://www.rubyrep.org/ - Ruby based, asynchronous, multi-master replication system, which supports Postgres and MySQL.<br />
<br />
* "pg_comparator" - BSD License - http://pgfoundry.org/projects/pg-comparator/ - Perl-based, table-level async master-slave "diff" and "patch" method of replication. Low configuration overhead.<br />
<br />
===Inactive projects===<br />
* [http://www.slony2.org/ Slony-II]<br />
* PGReplication<br />
<br />
==Clustering==<br />
<br />
* [http://www.greenplum.com/index.php?page=greenplum-database Greenplum Database] (formerly Bizgres MPP), proprietary. Not so much a replication solution as a way to parallelize queries, and targeted at the data warehousing crowd. Similar to ExtenDB, but tightly integrated with PostgreSQL.<br />
<br />
*[http://www.enterprisedb.com/products/gridsql.do GridSQL for EnterpriseDB Advanced Server] (formerly ExtenDB) <br />
<br />
*sequoia (jdbc, formerly known as c-jdbc)<br />
<br />
==Connection Pooling and Acceleration==<br />
<br />
Connection pooling programs let you reduce database-related overhead when it's the sheer number of physical connections dragging performance down. This is particularly important on Windows, where system limitations prevent large number of connections; see "I cannot run with more than about 125 connections at once" in the [http://www.postgresql.org/docs/faqs.FAQ_windows.html Windows FAQ]. It's also vital for web applications where the number of connections can get very large.<br />
<br />
Some programs that implement connection pooling are:<br />
* [https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer PgBouncer]<br />
* [http://pgpool.projects.postgresql.org/ pgpool]<br />
* [http://kaiv.wordpress.com/2007/07/27/postgresql-cluster-partitioning-with-plproxy-part-i/ plproxy]<br />
<br />
Some people also or alternately use [http://www.danga.com/memcached/ memcached] in various ways to reduce the work the database handles directly by caching popular data.<br />
<br />
==Credits==<br />
<br />
Sources for the initial information on this page include:<br />
*[http://archives.postgresql.org/pgsql-performance/2007-06/msg00264.php replication thread]<br />
*[http://archives.postgresql.org/pgsql-general/2007-08/msg00085.php pgpool2 vs sequoia]<br />
*[http://archives.postgresql.org/pgsql-hackers/2006-10/msg00810.php Postgresql Caching]<br />
<br />
A existing page covering this topic in German is at http://burger-ag.de/postgresql_replikation.whtml It translates pretty well through [http://babelfish.altavista.com/ Babelfish].<br />
<br />
Sources for more information located but not yet integrated into here:<br />
* [http://bristlecone.continuent.org/uploads/bristlecone/HomePage/PG_East-Scale-Out-Benchmarks_FINAL2.pdf Portable Scale-Out Benchmarks for PostgreSQL] by Robert Hodges<br />
* [http://www.fastware.com.au/docs/PostgreSQL_HighAvailability.pdf High Availability and PostgreSQL] by Gavin Sherry<br />
<br />
[[Category:Replication]]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=Replication,_Clustering,_and_Connection_Pooling&diff=8768Replication, Clustering, and Connection Pooling2009-11-19T04:07:08Z<p>Martin.pihlak: /* Comparison matrix */</p>
<hr />
<div>==Introduction==<br />
There are many approaches available to scale PostgreSQL beyond running on a single server. An outline of the terminology and basic technologies involved is at [http://www.postgresql.org/docs/current/interactive/high-availability.html High Availability and Load Balancing]. There is a [http://momjian.us/main/writings/pgsql/replication.pdf presentation] covering some of these solutions.<br />
<br />
There is no one-size fits all replication software. You have to understand your requirements and how various approaches fit into that. For example, here are two extremes in the replication problem space:<br />
<br />
* You have a few servers connected to a local network you want to always keep current for failover and load-balancing purposes. Here you would be considering solutions that are synchronous, eager, and therefore conflict-free.<br />
* Your users take a local copy of the database with them on laptops when they leave the office, make changes while they are away, and need to merge those with the main database when they return. Here you'd want an asynchronous, lazy replication approach, and will be forced to consider how to handle conflicts in cases where the same record has been modified both on the master server and on a local copy.<br />
<br />
These are both database replication problems, but the best way to solve them is very different. And as you can see from these examples, replication has a lot of specific terminology that you'll have to understand to figure out what class of solution makes sense for your requirements. A great source for this background is in the<br />
[http://www.postgres-r.org/documentation/terms Postgres-R Terms and Definitions for Database Replication]. The main theoretical topic it doesn't mention is how to resolve conflict resolution in lazy replication cases like the laptop situation, which involves voting and similar schemes.<br />
<br />
==Features in the Core of PostgreSQL==<br />
The PostgreSQL core team considered replication and clustering technology outside the scope of the main project's focus but this changed in Spring 2008, see the [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php Core Team's statement].<br />
<br />
*[[Warm Standby]]/Log Shipping is a HA solution which 'replicates' a database cluster to an archive or a warm (can be brought up quickly, but not available for querying) standby server. Overhead is very low and it's easy to set up. This is the simplest and best solution if all you care about is continuous backup and short failover times.<br />
<br />
*There's an ongoing project to integrate hot standby capabilites (read only queries on slave) into PostgreSQL...if/when complete, this would provide a replication mechanism similar to, but significantly better than mysql binary log replication, and would provide an excellent complement to slony. See [[Hot Standby]].<br />
<br />
==Comparison matrix==<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 100%; table-layout: fixed;"<br />
|- style="background: #ececec"<br />
! Program<br />
! License<br />
! Maturity<br />
! Replication Method<br />
! Sync<br />
! Connection Pooling<br />
! Load Balancing<br />
! Query Partitioning<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://www.pgcluster.org/ PGCluster]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | See version details on site<br />
| bgcolor="#ffffaa" | Master-Master<br />
| bgcolor="#ffffaa" | Synchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ddffdd" | Yes<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | '''pgpool-I'''<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Stable<br />
| bgcolor="#ffffaa" | Statement-Based Middleware<br />
| bgcolor="#ffffaa" | Synchronous<br />
| bgcolor="#ddffdd" | Yes<br />
| bgcolor="#ddffdd" | Yes<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://pgpool.projects.postgresql.org/ pgpool-II]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Recent release<br />
| bgcolor="#ffffaa" | Statement-Based Middleware<br />
| bgcolor="#ffffaa" | Synchronous<br />
| bgcolor="#ddffdd" | Yes<br />
| bgcolor="#ddffdd" | Yes<br />
| bgcolor="#ddffdd" | Yes<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://slony.info/ slony-I]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Stable<br />
| bgcolor="#ffffaa" | Master-Slave<br />
| bgcolor="#ffffaa" | Asynchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://bucardo.org/ Bucardo]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Stable<br />
| bgcolor="#ffffaa" | Master-Master, Master-Slave<br />
| bgcolor="#ffffaa" | Asynchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [https://developer.skype.com/SkypeGarage/DbProjects/SkyTools Londiste]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Stable<br />
| bgcolor="#ffffaa" | Master-Slave<br />
| bgcolor="#ffffaa" | Asynchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://www.commandprompt.com/products/mammothreplicator/ Mammoth]<br />
| bgcolor="#ffffaa" | BSD<br />
| bgcolor="#ffffaa" | Stable<br />
| bgcolor="#ffffaa" | Master-Slave<br />
| bgcolor="#ffffaa" | Asynchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
|-<br />
! style="text-align:block;" bgcolor="#ececec" | [http://www.rubyrep.org/ rubyrep]<br />
| bgcolor="#ffffaa" | MIT<br />
| bgcolor="#ffffaa" | Recent Release<br />
| bgcolor="#ffffaa" | Master-Master, Master-Slave<br />
| bgcolor="#ffffaa" | Asynchronous<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
| bgcolor="#ffaaaa" | No<br />
|}<br />
<br />
==Replication==<br />
<br />
Aside from Warm Standby, mentioned above...<br />
<br />
*Slony-I: Seems good, single master only, master is a single point of failure, no good failover system for electing a new master or having a failed master rejoin the cluster. Slave databases are mostly for safety or for parallelizing queries for performance. Suffers from O(N^2) communications (N = cluster size). with reasonable sysadmin you can implement failover system yourself. regarding communications, you can cascade the replication to reduce load on the master. If you were implementing a large replication cluster, this would probably be a good idea. Slony is powerful, trigger based, and highly configurable.<br />
<br />
* PGCluster: PGCluster (which, incidentally, is not the same as PGCluster-II, a shared-disk solution), which does synchronous multimaster replication. Two single-points failure spots, load balancer and the data replicator. The project has historically looked a bit dead, but they just released a new version and moved to a Trac-based web site at http://www.pgcluster.org/ and http://pgfoundry.org/projects/pgcluster is up to date (at least downloads page) One major downside to PGCluster is that it uses a modified version of PostgreSQL, and it usually lags a few releases behind.<br />
<br />
* http://pgpool.projects.postgresql.org/ pgpool 1/2 is a reasonable solution. it's statement level replication, which has some downsides, but is good for certain things. pgpool 2 has a neat distributed table mechanism which is interesting. You might want to be looking here if you have extremely high ratios of read to write but need to service a huge transaction volume. Supports load-balancing and replication by implementing a proxy that duplicates all updates to all slaves. It can partition data by doing this, and it can semi-intelligently route queries to the appropriate servers.<br />
<br />
* "Mammoth Replicator" - BSD - http://www.commandprompt.com/products/mammothreplicator/ - Former proprietary solution, now open source. Uses a central logging process to distribute data changes amongst nodes. Essentially a fork of Postgres, as the changes are written directly into the backend. <br />
<br />
* "Bucardo" - BSD License - http://bucardo.org/ - Trigger-based, asynchronous, multi-master or master-slave, written using plperl.<br />
<br />
* Cybertec, an Austrian company, offers a proprietary packaging of PGCluster. They simply call it PostgreSQL Multimaster-Replication, see http://www.cybertec.at.<br />
<br />
* [[Londiste_Tutorial|Londiste]], a part of [[Skytools]] (https://developer.skype.com/SkypeGarage/DbProjects/SkyTools) which is a collection of replication tools from the Skype people. Purports to be simpler to use than Slony.<br />
<br />
* [http://www.continuent.com/index.php?option=com_content&task=view&id=212&Itemid=169 Continuent uni/cluster], proprietary and the related Sequoia (jdbc, formerly known as c-jdbc)<br />
<br />
* [http://www.postgres-r.org Postgres-R] is still in development. It features eager and thus conflict-free, but async multi-master replication.<br />
<br />
* DRBD (http://www.drbd.org/), a device driver that replicates disk blocks to other nodes. This works for failover only, not for scaling reads. Easy migration of devices if combined with an NFS export.<br />
<br />
* "Daffodil Replicator" - GPL - http://sourceforge.net/projects/daffodilreplica/ <br />
<br />
* "RubyRep" - MIT License - http://www.rubyrep.org/ - Ruby based, asynchronous, multi-master replication system, which supports Postgres and MySQL.<br />
<br />
* "pg_comparator" - BSD License - http://pgfoundry.org/projects/pg-comparator/ - Perl-based, table-level async master-slave "diff" and "patch" method of replication. Low configuration overhead.<br />
<br />
===Inactive projects===<br />
* [http://www.slony2.org/ Slony-II]<br />
* PGReplication<br />
<br />
==Clustering==<br />
<br />
* [http://www.greenplum.com/index.php?page=greenplum-database Greenplum Database] (formerly Bizgres MPP), proprietary. Not so much a replication solution as a way to parallelize queries, and targeted at the data warehousing crowd. Similar to ExtenDB, but tightly integrated with PostgreSQL.<br />
<br />
*[http://www.enterprisedb.com/products/gridsql.do GridSQL for EnterpriseDB Advanced Server] (formerly ExtenDB) <br />
<br />
*sequoia (jdbc, formerly known as c-jdbc)<br />
<br />
==Connection Pooling and Acceleration==<br />
<br />
Connection pooling programs let you reduce database-related overhead when it's the sheer number of physical connections dragging performance down. This is particularly important on Windows, where system limitations prevent large number of connections; see "I cannot run with more than about 125 connections at once" in the [http://www.postgresql.org/docs/faqs.FAQ_windows.html Windows FAQ]. It's also vital for web applications where the number of connections can get very large.<br />
<br />
Some programs that implement connection pooling are:<br />
* [https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer PgBouncer]<br />
* [http://pgpool.projects.postgresql.org/ pgpool]<br />
* [http://kaiv.wordpress.com/2007/07/27/postgresql-cluster-partitioning-with-plproxy-part-i/ plproxy]<br />
<br />
Some people also or alternately use [http://www.danga.com/memcached/ memcached] in various ways to reduce the work the database handles directly by caching popular data.<br />
<br />
==Credits==<br />
<br />
Sources for the initial information on this page include:<br />
*[http://archives.postgresql.org/pgsql-performance/2007-06/msg00264.php replication thread]<br />
*[http://archives.postgresql.org/pgsql-general/2007-08/msg00085.php pgpool2 vs sequoia]<br />
*[http://archives.postgresql.org/pgsql-hackers/2006-10/msg00810.php Postgresql Caching]<br />
<br />
A existing page covering this topic in German is at http://burger-ag.de/postgresql_replikation.whtml It translates pretty well through [http://babelfish.altavista.com/ Babelfish].<br />
<br />
Sources for more information located but not yet integrated into here:<br />
* [http://bristlecone.continuent.org/uploads/bristlecone/HomePage/PG_East-Scale-Out-Benchmarks_FINAL2.pdf Portable Scale-Out Benchmarks for PostgreSQL] by Robert Hodges<br />
* [http://www.fastware.com.au/docs/PostgreSQL_HighAvailability.pdf High Availability and PostgreSQL] by Gavin Sherry<br />
<br />
[[Category:Replication]]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=PGCon2009JapanClusterDeveloperMeeting&diff=8757PGCon2009JapanClusterDeveloperMeeting2009-11-18T02:40:06Z<p>Martin.pihlak: /* Plans for future development */</p>
<hr />
<div>== Participants' Input to the Meeting ==<br />
<br />
This is the first PostgreSQL cluster developers meeting. The meeting is held as an associated event of PostgreSQL Conference 2009 Japan. For the detail of the meeting, please visit [http://www.postgresql.jp/events/pgcon09j/e/dev_mtg Call for Participants].<br />
<br />
Participants of the meeting is encouraged to submit inputs to the meeting to this page. Organizational information can be found here: [[PostgreSQL_Conference_2009_Japan]].<br />
<br />
== Links to Information about Clustering Solutions ==<br />
<br />
Please put links here to software, background material, presentations, and other information about your particular clustering software. <br />
<br />
=== Notes On General Design ===<br />
<br />
Both for this page and for your 5-minute presentation, please try to answer the following questions about your current solution:<br />
<br />
* What is the primary use-case your solution is designed for?<br />
* General Design<br />
** What's the general clustering architecture of your software? (e.g. statement replication, shared memory, GCS, clustered table, etc.)<br />
** Does it consist of a collection of tools or a monolithic control-and-management architecture?<br />
** Does your solution supply administration and monitoring tools?<br />
** Is your solution intended to be generic, or does it require the user's application to be built around the clustering architecture?<br />
** Does the solution require patches on core PostgreSQL, or is it entirely external?<br />
* Availability: how does your software deal with uptime availablity?<br />
** Is failover automated?<br />
** Is data synchronous between nodes or asynchrnous?<br />
** What failure conditions can it protect against, and which can't it?<br />
** Does it work over a WAN or do clustered machines have to be in the same data center?<br />
* Scalability: how does your software help with horizontal scaling?<br />
** How does it scale for reads, if at all?<br />
** How does it scale for writes, if at all?<br />
** Is it more designed to scale for many small queries, a few large queries, or for geographic distrubution?<br />
** What kinds of non-simple-query operations (reporting queries, stored procedures, triggers, etc.) can it handle, and which can it not?<br />
* Status: what's the project's current development and adoption status?<br />
** Is it still under active development?<br />
** How mature is it? prototype / beta / first release / second release / in maintenance<br />
** How widely adopted is it? Is it used only by customers of the developers, or by PostgreSQL users in general?<br />
<br />
=== Links ===<br />
<br />
*Some theory:<br />
**[http://www.cs.purdue.edu/homes/bb/cs542-05Spr/ParallelDBMS.ppt Basics about DB clustering] by Tamer Özsu & Patrick Valduriez<br />
<br />
*DB Cluster softwares:<br />
**Slony-I: [http://www.slony.info/documentation/ Documentation]<br />
**pgpool-II: [http://pgpool.projects.postgresql.org/ Home Page]<br />
**pgbouncer: [http://pgbouncer.projects.postgresql.org/ Project Home Page]<br />
**PL/Proxy: [http://pgfoundry.org/projects/plproxy/ PGFoundry Home Page]<br />
**PgCluster: [http://pgfoundry.org/projects/pgcluster/ PGFoundry Home Page]<br />
**Postgres-R: [http://www.postgres-r.org/ Project Home Page] (see esp. the [http://www.postgres-r.org/downloads/concept.pdf concept document] and the [http://www.postgres-r.org/documentation/references references] for related scientific papers)<br />
**PostgresForest: [http://www.nttdata.co.jp/services/postgresforest/ Home Page in Japanese]<br />
**Bucardo: [http://bucardo.org/wiki/Main_Page Project Home Page]<br />
**GridSQL: [http://www.enterprisedb.com/community/projects/gridsql.do#ui-tabs-57 Architecture Page]<br />
**Postgres-2: [http://wiki.postgresql.org/wiki/Postgres-2 Postgres-2 Introduction Page]<br />
**Streaming Replication: [http://wiki.postgresql.org/wiki/Streaming_Replication Project Home Page]<br />
<br />
== Clustering Marketplace ==<br />
<br />
What do you think current commercial and user demand for clustering is? Are users trying to get scalability, availability, or other benefits from Clustering? Has interest in clustering waned or grown?<br />
<br />
Josh Says: I've seen the desire for an "Oracle RAC Replacement" is less prominent, at least in the USA, than it was a few years ago. It's possible that folks are realizing that RAC has a lot of drawbacks, or it may just be that I don't talk to Oracle users as much. People seem to be looking more for clustering to help with horizontal scalability, especially to help with performance on cloud hosting platforms, which is a big source of demand now. With MySQL in trouble, people are really looking for an "approximate consistency, low administration" solution to replace MySQL Replication & NDB.<br />
<br />
== Challenges and Issues ==<br />
<br />
What challenges are you currently facing in working on clustering and replication? What things do you think should be different about core Postgres or developed in common?<br />
<br />
== Agenda For Day ==<br />
<br />
Please contribute to this agenda! It is not yet final, but we do need to have a list of items people want to talk about before the meeting itself. If you add an item to the agenda, please put your name next to it so we know who to call to start the item.<br />
<br />
The meeting will run from 9:30AM to 5:30PM.<br />
<br />
=== Introduction ===<br />
<br />
Current clustering definitions, use cases and customer goals (1/2 hour short presentation, Koichi-san and Josh Berkus)<br />
<br />
# User goals<br />
# Specific use cases<br />
# Current market for PostgreSQL clustering<br />
# Competitive market of other DBMSes<br />
<br />
=== Review of Existing Projects ===<br />
<br />
Each project team will be welcome to give a 5-minute presentation about<br />
your current development work on your clustering or replication solution<br />
near the beginning of the event. Note that you are NOT obligated to<br />
give this presentation; if you feel that your current efforts are well<br />
enough known, or if you have no time to prepare, you may choose not to<br />
give a presentation.<br />
<br />
In order to have a productive day, please design your presentation around the following:<br />
* Presentations will be 5 minutes only, strictly timed.<br />
* In order to support (1), presentations will be given on *my* laptop using PDF slides. Please bring a PDF with you to the meeting, or (better) e-mail it to me before the meeting.<br />
* Please discuss *current* work on your software and challenges you are currently facing. Summaries of the history or features of your solution are unnecessary unless they have changed in the last year. Instead, link to these on the wiki.<br />
<br />
Each team which is giving a presentation should sign up below:<br />
<br />
* Postgres-R: Flashlight (Markus Wanner)<br />
* Streaming Replication: [[Media:SR ClusterSummit.pdf]] (Fujii)<br />
<br />
=== Future Requirements and Expectations ===<br />
<br />
Discussion: please add any discussion items you have around the future of database clustering, the demand for it, and user needs around clustering:<br />
<br />
# Common issues to several products<br />
#* Usability<br />
#* Administration<br />
# Application or industry specific issues<br />
<br />
=== Technical Issues in clustering design ===<br />
<br />
Please add any items you have around specific technical issues in clustering design, especially unsolved or recently solved ones:<br />
<br />
# Challenges<br />
#* High Availability<br />
#* Scalability (read/write)<br />
# Specifications and APIs<br />
<br />
=== Plans for future development ===<br />
<br />
Please add any items you want to discuss around future development, especially development involving a collaboration between teams or with the general PostgreSQL community.<br />
<br />
# To be developed in core PostgreSQL<br />
#* ReplicationHooks -- where did they go?<br />
#* Standby/replication (sync/async)/partitioning<br />
#* Transaction Management<br />
#* 2PC callback functions?<br />
#* APIs and interfaces<br />
#* Tools<br />
#* (MW) common unit and/or regression testing harness?<br />
#* (MW) common benchmark framework?<br />
#* libpq improvements (keepalive / query timeout, full duplex)<br />
<br />
# To be developed separately<br />
# Merging clustering projects/products?<br />
<br />
=== Schedule and Map ===<br />
<br />
Meeting Schedule and the map from stations near by will be found in [[Media:Schedule_and_Map.pdf]].<br />
<br />
== Contact Information ==<br />
<br />
Communication for the clustering summit has been on Josh Berkus's clustering@berkus.org mailing list.<br />
<br />
Phone numbers for Koichi Suzuki, Michael Paquier and Josh Berkus have been sent by e-mail. Note that many/most foreign cell phones do not work in Japan.<br />
<br />
Please list below your name and the hotel you are staying at in case we need to find you:<br />
<br />
* Josh Berkus: Shiba Park Hotel<br />
* Bruce Momjian: Park Tokyo Hotel<br />
* Jan Wieck: Park Hotel Tokyo<br />
* Markus Wanner: Shiba Park Hotel<br />
<br />
== Miscellaneous Travel Tips ==<br />
<br />
* Suica Card: Foreign Passport Holders can purchase a Suica + NEX package at Narita Airport for 3500 Yen. It consists of a one-way fare NEX to Tokyo and a 1500 Yen precharged Suica chipcard, that can be used on underground trains in Tokyo (plus 500 Yen deposit for the card). Considering that the one-way fare of NEX is 3000 Yen alone, that looks like a great deal. See http://www.japan-guide.com/e/e2359_002.html for details. -- Jan<br />
<br />
[[Category:PostgreSQL Events]]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=PGCon2009JapanClusterDeveloperMeeting&diff=8756PGCon2009JapanClusterDeveloperMeeting2009-11-18T02:29:21Z<p>Martin.pihlak: /* Plans for future development */</p>
<hr />
<div>== Participants' Input to the Meeting ==<br />
<br />
This is the first PostgreSQL cluster developers meeting. The meeting is held as an associated event of PostgreSQL Conference 2009 Japan. For the detail of the meeting, please visit [http://www.postgresql.jp/events/pgcon09j/e/dev_mtg Call for Participants].<br />
<br />
Participants of the meeting is encouraged to submit inputs to the meeting to this page. Organizational information can be found here: [[PostgreSQL_Conference_2009_Japan]].<br />
<br />
== Links to Information about Clustering Solutions ==<br />
<br />
Please put links here to software, background material, presentations, and other information about your particular clustering software. <br />
<br />
=== Notes On General Design ===<br />
<br />
Both for this page and for your 5-minute presentation, please try to answer the following questions about your current solution:<br />
<br />
* What is the primary use-case your solution is designed for?<br />
* General Design<br />
** What's the general clustering architecture of your software? (e.g. statement replication, shared memory, GCS, clustered table, etc.)<br />
** Does it consist of a collection of tools or a monolithic control-and-management architecture?<br />
** Does your solution supply administration and monitoring tools?<br />
** Is your solution intended to be generic, or does it require the user's application to be built around the clustering architecture?<br />
** Does the solution require patches on core PostgreSQL, or is it entirely external?<br />
* Availability: how does your software deal with uptime availablity?<br />
** Is failover automated?<br />
** Is data synchronous between nodes or asynchrnous?<br />
** What failure conditions can it protect against, and which can't it?<br />
** Does it work over a WAN or do clustered machines have to be in the same data center?<br />
* Scalability: how does your software help with horizontal scaling?<br />
** How does it scale for reads, if at all?<br />
** How does it scale for writes, if at all?<br />
** Is it more designed to scale for many small queries, a few large queries, or for geographic distrubution?<br />
** What kinds of non-simple-query operations (reporting queries, stored procedures, triggers, etc.) can it handle, and which can it not?<br />
* Status: what's the project's current development and adoption status?<br />
** Is it still under active development?<br />
** How mature is it? prototype / beta / first release / second release / in maintenance<br />
** How widely adopted is it? Is it used only by customers of the developers, or by PostgreSQL users in general?<br />
<br />
=== Links ===<br />
<br />
*Some theory:<br />
**[http://www.cs.purdue.edu/homes/bb/cs542-05Spr/ParallelDBMS.ppt Basics about DB clustering] by Tamer Özsu & Patrick Valduriez<br />
<br />
*DB Cluster softwares:<br />
**Slony-I: [http://www.slony.info/documentation/ Documentation]<br />
**pgpool-II: [http://pgpool.projects.postgresql.org/ Home Page]<br />
**pgbouncer: [http://pgbouncer.projects.postgresql.org/ Project Home Page]<br />
**PL/Proxy: [http://pgfoundry.org/projects/plproxy/ PGFoundry Home Page]<br />
**PgCluster: [http://pgfoundry.org/projects/pgcluster/ PGFoundry Home Page]<br />
**Postgres-R: [http://www.postgres-r.org/ Project Home Page] (see esp. the [http://www.postgres-r.org/downloads/concept.pdf concept document] and the [http://www.postgres-r.org/documentation/references references] for related scientific papers)<br />
**PostgresForest: [http://www.nttdata.co.jp/services/postgresforest/ Home Page in Japanese]<br />
**Bucardo: [http://bucardo.org/wiki/Main_Page Project Home Page]<br />
**GridSQL: [http://www.enterprisedb.com/community/projects/gridsql.do#ui-tabs-57 Architecture Page]<br />
**Postgres-2: [http://wiki.postgresql.org/wiki/Postgres-2 Postgres-2 Introduction Page]<br />
**Streaming Replication: [http://wiki.postgresql.org/wiki/Streaming_Replication Project Home Page]<br />
<br />
== Clustering Marketplace ==<br />
<br />
What do you think current commercial and user demand for clustering is? Are users trying to get scalability, availability, or other benefits from Clustering? Has interest in clustering waned or grown?<br />
<br />
Josh Says: I've seen the desire for an "Oracle RAC Replacement" is less prominent, at least in the USA, than it was a few years ago. It's possible that folks are realizing that RAC has a lot of drawbacks, or it may just be that I don't talk to Oracle users as much. People seem to be looking more for clustering to help with horizontal scalability, especially to help with performance on cloud hosting platforms, which is a big source of demand now. With MySQL in trouble, people are really looking for an "approximate consistency, low administration" solution to replace MySQL Replication & NDB.<br />
<br />
== Challenges and Issues ==<br />
<br />
What challenges are you currently facing in working on clustering and replication? What things do you think should be different about core Postgres or developed in common?<br />
<br />
== Agenda For Day ==<br />
<br />
Please contribute to this agenda! It is not yet final, but we do need to have a list of items people want to talk about before the meeting itself. If you add an item to the agenda, please put your name next to it so we know who to call to start the item.<br />
<br />
The meeting will run from 9:30AM to 5:30PM.<br />
<br />
=== Introduction ===<br />
<br />
Current clustering definitions, use cases and customer goals (1/2 hour short presentation, Koichi-san and Josh Berkus)<br />
<br />
# User goals<br />
# Specific use cases<br />
# Current market for PostgreSQL clustering<br />
# Competitive market of other DBMSes<br />
<br />
=== Review of Existing Projects ===<br />
<br />
Each project team will be welcome to give a 5-minute presentation about<br />
your current development work on your clustering or replication solution<br />
near the beginning of the event. Note that you are NOT obligated to<br />
give this presentation; if you feel that your current efforts are well<br />
enough known, or if you have no time to prepare, you may choose not to<br />
give a presentation.<br />
<br />
In order to have a productive day, please design your presentation around the following:<br />
* Presentations will be 5 minutes only, strictly timed.<br />
* In order to support (1), presentations will be given on *my* laptop using PDF slides. Please bring a PDF with you to the meeting, or (better) e-mail it to me before the meeting.<br />
* Please discuss *current* work on your software and challenges you are currently facing. Summaries of the history or features of your solution are unnecessary unless they have changed in the last year. Instead, link to these on the wiki.<br />
<br />
Each team which is giving a presentation should sign up below:<br />
<br />
* Postgres-R: Flashlight (Markus Wanner)<br />
* Streaming Replication: [[Media:SR ClusterSummit.pdf]] (Fujii)<br />
<br />
=== Future Requirements and Expectations ===<br />
<br />
Discussion: please add any discussion items you have around the future of database clustering, the demand for it, and user needs around clustering:<br />
<br />
# Common issues to several products<br />
#* Usability<br />
#* Administration<br />
# Application or industry specific issues<br />
<br />
=== Technical Issues in clustering design ===<br />
<br />
Please add any items you have around specific technical issues in clustering design, especially unsolved or recently solved ones:<br />
<br />
# Challenges<br />
#* High Availability<br />
#* Scalability (read/write)<br />
# Specifications and APIs<br />
<br />
=== Plans for future development ===<br />
<br />
Please add any items you want to discuss around future development, especially development involving a collaboration between teams or with the general PostgreSQL community.<br />
<br />
# To be developed in core PostgreSQL<br />
#* ReplicationHooks -- where did they go?<br />
#* Standby/replication (sync/async)/partitioning<br />
#* Transaction Management<br />
#* 2PC callback functions?<br />
#* APIs and interfaces<br />
#* Tools<br />
#* (MW) common unit and/or regression testing harness?<br />
#* (MW) common benchmark framework?<br />
<br />
# To be developed separately<br />
# Merging clustering projects/products?<br />
<br />
=== Schedule and Map ===<br />
<br />
Meeting Schedule and the map from stations near by will be found in [[Media:Schedule_and_Map.pdf]].<br />
<br />
== Contact Information ==<br />
<br />
Communication for the clustering summit has been on Josh Berkus's clustering@berkus.org mailing list.<br />
<br />
Phone numbers for Koichi Suzuki, Michael Paquier and Josh Berkus have been sent by e-mail. Note that many/most foreign cell phones do not work in Japan.<br />
<br />
Please list below your name and the hotel you are staying at in case we need to find you:<br />
<br />
* Josh Berkus: Shiba Park Hotel<br />
* Bruce Momjian: Park Tokyo Hotel<br />
* Jan Wieck: Park Hotel Tokyo<br />
* Markus Wanner: Shiba Park Hotel<br />
<br />
== Miscellaneous Travel Tips ==<br />
<br />
* Suica Card: Foreign Passport Holders can purchase a Suica + NEX package at Narita Airport for 3500 Yen. It consists of a one-way fare NEX to Tokyo and a 1500 Yen precharged Suica chipcard, that can be used on underground trains in Tokyo (plus 500 Yen deposit for the card). Considering that the one-way fare of NEX is 3000 Yen alone, that looks like a great deal. See http://www.japan-guide.com/e/e2359_002.html for details. -- Jan<br />
<br />
[[Category:PostgreSQL Events]]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=PGCon2009JapanClusterDeveloperMeeting&diff=8755PGCon2009JapanClusterDeveloperMeeting2009-11-18T02:26:58Z<p>Martin.pihlak: /* Plans for future development */</p>
<hr />
<div>== Participants' Input to the Meeting ==<br />
<br />
This is the first PostgreSQL cluster developers meeting. The meeting is held as an associated event of PostgreSQL Conference 2009 Japan. For the detail of the meeting, please visit [http://www.postgresql.jp/events/pgcon09j/e/dev_mtg Call for Participants].<br />
<br />
Participants of the meeting is encouraged to submit inputs to the meeting to this page. Organizational information can be found here: [[PostgreSQL_Conference_2009_Japan]].<br />
<br />
== Links to Information about Clustering Solutions ==<br />
<br />
Please put links here to software, background material, presentations, and other information about your particular clustering software. <br />
<br />
=== Notes On General Design ===<br />
<br />
Both for this page and for your 5-minute presentation, please try to answer the following questions about your current solution:<br />
<br />
* What is the primary use-case your solution is designed for?<br />
* General Design<br />
** What's the general clustering architecture of your software? (e.g. statement replication, shared memory, GCS, clustered table, etc.)<br />
** Does it consist of a collection of tools or a monolithic control-and-management architecture?<br />
** Does your solution supply administration and monitoring tools?<br />
** Is your solution intended to be generic, or does it require the user's application to be built around the clustering architecture?<br />
** Does the solution require patches on core PostgreSQL, or is it entirely external?<br />
* Availability: how does your software deal with uptime availablity?<br />
** Is failover automated?<br />
** Is data synchronous between nodes or asynchrnous?<br />
** What failure conditions can it protect against, and which can't it?<br />
** Does it work over a WAN or do clustered machines have to be in the same data center?<br />
* Scalability: how does your software help with horizontal scaling?<br />
** How does it scale for reads, if at all?<br />
** How does it scale for writes, if at all?<br />
** Is it more designed to scale for many small queries, a few large queries, or for geographic distrubution?<br />
** What kinds of non-simple-query operations (reporting queries, stored procedures, triggers, etc.) can it handle, and which can it not?<br />
* Status: what's the project's current development and adoption status?<br />
** Is it still under active development?<br />
** How mature is it? prototype / beta / first release / second release / in maintenance<br />
** How widely adopted is it? Is it used only by customers of the developers, or by PostgreSQL users in general?<br />
<br />
=== Links ===<br />
<br />
*Some theory:<br />
**[http://www.cs.purdue.edu/homes/bb/cs542-05Spr/ParallelDBMS.ppt Basics about DB clustering] by Tamer Özsu & Patrick Valduriez<br />
<br />
*DB Cluster softwares:<br />
**Slony-I: [http://www.slony.info/documentation/ Documentation]<br />
**pgpool-II: [http://pgpool.projects.postgresql.org/ Home Page]<br />
**pgbouncer: [http://pgbouncer.projects.postgresql.org/ Project Home Page]<br />
**PL/Proxy: [http://pgfoundry.org/projects/plproxy/ PGFoundry Home Page]<br />
**PgCluster: [http://pgfoundry.org/projects/pgcluster/ PGFoundry Home Page]<br />
**Postgres-R: [http://www.postgres-r.org/ Project Home Page] (see esp. the [http://www.postgres-r.org/downloads/concept.pdf concept document] and the [http://www.postgres-r.org/documentation/references references] for related scientific papers)<br />
**PostgresForest: [http://www.nttdata.co.jp/services/postgresforest/ Home Page in Japanese]<br />
**Bucardo: [http://bucardo.org/wiki/Main_Page Project Home Page]<br />
**GridSQL: [http://www.enterprisedb.com/community/projects/gridsql.do#ui-tabs-57 Architecture Page]<br />
**Postgres-2: [http://wiki.postgresql.org/wiki/Postgres-2 Postgres-2 Introduction Page]<br />
**Streaming Replication: [http://wiki.postgresql.org/wiki/Streaming_Replication Project Home Page]<br />
<br />
== Clustering Marketplace ==<br />
<br />
What do you think current commercial and user demand for clustering is? Are users trying to get scalability, availability, or other benefits from Clustering? Has interest in clustering waned or grown?<br />
<br />
Josh Says: I've seen the desire for an "Oracle RAC Replacement" is less prominent, at least in the USA, than it was a few years ago. It's possible that folks are realizing that RAC has a lot of drawbacks, or it may just be that I don't talk to Oracle users as much. People seem to be looking more for clustering to help with horizontal scalability, especially to help with performance on cloud hosting platforms, which is a big source of demand now. With MySQL in trouble, people are really looking for an "approximate consistency, low administration" solution to replace MySQL Replication & NDB.<br />
<br />
== Challenges and Issues ==<br />
<br />
What challenges are you currently facing in working on clustering and replication? What things do you think should be different about core Postgres or developed in common?<br />
<br />
== Agenda For Day ==<br />
<br />
Please contribute to this agenda! It is not yet final, but we do need to have a list of items people want to talk about before the meeting itself. If you add an item to the agenda, please put your name next to it so we know who to call to start the item.<br />
<br />
The meeting will run from 9:30AM to 5:30PM.<br />
<br />
=== Introduction ===<br />
<br />
Current clustering definitions, use cases and customer goals (1/2 hour short presentation, Koichi-san and Josh Berkus)<br />
<br />
# User goals<br />
# Specific use cases<br />
# Current market for PostgreSQL clustering<br />
# Competitive market of other DBMSes<br />
<br />
=== Review of Existing Projects ===<br />
<br />
Each project team will be welcome to give a 5-minute presentation about<br />
your current development work on your clustering or replication solution<br />
near the beginning of the event. Note that you are NOT obligated to<br />
give this presentation; if you feel that your current efforts are well<br />
enough known, or if you have no time to prepare, you may choose not to<br />
give a presentation.<br />
<br />
In order to have a productive day, please design your presentation around the following:<br />
* Presentations will be 5 minutes only, strictly timed.<br />
* In order to support (1), presentations will be given on *my* laptop using PDF slides. Please bring a PDF with you to the meeting, or (better) e-mail it to me before the meeting.<br />
* Please discuss *current* work on your software and challenges you are currently facing. Summaries of the history or features of your solution are unnecessary unless they have changed in the last year. Instead, link to these on the wiki.<br />
<br />
Each team which is giving a presentation should sign up below:<br />
<br />
* Postgres-R: Flashlight (Markus Wanner)<br />
* Streaming Replication: [[Media:SR ClusterSummit.pdf]] (Fujii)<br />
<br />
=== Future Requirements and Expectations ===<br />
<br />
Discussion: please add any discussion items you have around the future of database clustering, the demand for it, and user needs around clustering:<br />
<br />
# Common issues to several products<br />
#* Usability<br />
#* Administration<br />
# Application or industry specific issues<br />
<br />
=== Technical Issues in clustering design ===<br />
<br />
Please add any items you have around specific technical issues in clustering design, especially unsolved or recently solved ones:<br />
<br />
# Challenges<br />
#* High Availability<br />
#* Scalability (read/write)<br />
# Specifications and APIs<br />
<br />
=== Plans for future development ===<br />
<br />
Please add any items you want to discuss around future development, especially development involving a collaboration between teams or with the general PostgreSQL community.<br />
<br />
# To be developed in core PostgreSQL<br />
#* ReplicationHooks -- where did they go?<br />
#* Standby/replication (sync/async)/partitioning<br />
#* Transaction Management<br />
#* APIs and interfaces<br />
#* Tools<br />
#* (MW) common unit and/or regression testing harness?<br />
#* (MW) common benchmark framework?<br />
#* 2PC callback functions?<br />
<br />
# To be developed separately<br />
# Merging clustering projects/products?<br />
<br />
=== Schedule and Map ===<br />
<br />
Meeting Schedule and the map from stations near by will be found in [[Media:Schedule_and_Map.pdf]].<br />
<br />
== Contact Information ==<br />
<br />
Communication for the clustering summit has been on Josh Berkus's clustering@berkus.org mailing list.<br />
<br />
Phone numbers for Koichi Suzuki, Michael Paquier and Josh Berkus have been sent by e-mail. Note that many/most foreign cell phones do not work in Japan.<br />
<br />
Please list below your name and the hotel you are staying at in case we need to find you:<br />
<br />
* Josh Berkus: Shiba Park Hotel<br />
* Bruce Momjian: Park Tokyo Hotel<br />
* Jan Wieck: Park Hotel Tokyo<br />
* Markus Wanner: Shiba Park Hotel<br />
<br />
== Miscellaneous Travel Tips ==<br />
<br />
* Suica Card: Foreign Passport Holders can purchase a Suica + NEX package at Narita Airport for 3500 Yen. It consists of a one-way fare NEX to Tokyo and a 1500 Yen precharged Suica chipcard, that can be used on underground trains in Tokyo (plus 500 Yen deposit for the card). Considering that the one-way fare of NEX is 3000 Yen alone, that looks like a great deal. See http://www.japan-guide.com/e/e2359_002.html for details. -- Jan<br />
<br />
[[Category:PostgreSQL Events]]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-11&diff=3848CommitFest 2008-112008-12-15T20:44:37Z<p>Martin.pihlak: /* Miscellaneous */</p>
<hr />
<div>__TOC__<br />
<br />
This is the page for the CommitFest starting '''2008 November'''.<br />
<br />
Managers for this CommitFest are Josh Berkus (josh-at-agliodbs-com) and Dave Page (dpage-at-pgadmin-org).<br />
<br />
{{CommitFestCurrent}}<br />
<br />
== Pending patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
|-<br />
| colspan="4" |<br />
=== SE-PostgreSQL and related ===<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei|status=Waiting on Author|reviewers=Tom Lane, Simon Riggs, Bruce Momjian}}<br />
{{comment|KaiGai|[[SEPostgreSQL]] is a draft of comprehensive document}}<br />
{{comment|KaiGai|{{messageLink|4938F7FA.60805@ak.jp.nec.com|The latest patches to be reviewed (r1280), as of Dec. 5}}}}<br />
{{comment|CM|Dec. 14 status: KaiGai is {{messageLink|4945AC13.6000906@ak.jp.nec.com|working on version 6 }} }}<br />
<br />
{{patch|20080901063855.GJ16005@tamriel.snowman.net|Column-level Permissions|Stephen Frost|status=Waiting on Author|reviewers=Markus Wanner,Alvaro Herrera}}<br />
{{comment|Stephen Frost|Updated patch {{messageLink|20080902221823.GL16005@tamriel.snowman.net|here}}}}<br />
{{review|48DB48AC.5010400@bluegap.ch|Markus Wanner|Awaiting updated patch.}}<br />
{{comment|Stephen Frost|Updated patch, again, {{messageLink|20081102034517.GR4452@tamriel.snowman.net|here}}}}<br />
{{comment|Stephen Frost|Updated patch, fixes case where unprivileged user can get row count, {{messageLink|20081102131332.GU4452@tamriel.snowman.net|here}}}}<br />
{{comment|alvherre|{{messageLink|20081114135033.GD3830@alvh.no-ip.org|Updated patch}}}}<br />
{{comment|Robert Haas|Stephen Frost agreed to make {{messageLink|20081125210308.GD4452@tamriel.snowman.net|some minor changes}} 2008-11-25}}<br />
{{comment|CM|Dec. 14 status: no update from author; queried}}<br />
|-<br />
| colspan="4" |<br />
<br />
=== Recovery, Replication, Hot Standby ===<br />
<br />
{{patch|1220213074.4371.173.camel@ebony.2ndQuadrant|Infrastructure changes for recovery|status=Waiting on author|Simon Riggs|reviewers=Tom Lane, Heikki Linnakangas}} <br />
{{comment|sriggs| important patch for other work}}<br />
{{comment|Robert Haas|{{messageLink|1223472898.4747.310.camel@ebony.2ndQuadrant|patch v9}} here, in response to {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's review}}}}<br />
{{comment|sriggs|some issues overlooked, fixed as part of Hot Standby patch only at present}}<br />
{{comment|sriggs|do we want this split out again as a separate patch for easier review?}}<br />
{{comment|Robert Haas|looks like the consensus is that this should be {{messageLink|2e78013d0811200149t29173598m5eb70f62c1dc02d4@mail.gmail.com|split back out as a separate patch}}}}<br />
{{comment|Dave Page|Heikki reports he is waiting on Simon for a split set of patches 2008-11-27}}<br />
{{comment|CM|Dec. 14 status: author queried on status}}<br />
<br />
{{patch|1225557138.3971.673.camel@ebony.2ndQuadrant|Hot Standby - queries during archive recovery|status=Pending Review|Simon Riggs|reviewers=Pavan Deolasee, Koichi Suzuki}}<br />
{{comment|sriggs| v5d now available, fixing all Mark's reported issues. Main parts are fully reviewable}}<br />
{{comment|sriggs| Wiki contains dynamically updated list of outstanding items [[Hot_Standby]] }}<br />
{{comment|CM|Dec. 14 status: Author queried on status}}<br />
<br />
{{patch|1220174867.4371.107.camel@ebony.2ndQuadrant|rmgr hooks and contrib/rmgr_hook|status=Waiting on dependencies|Simon Riggs}} <br />
{{comment|sriggs| deferrable, if required}}<br />
{{comment|tgl|I think the plan is for this to wait till "infrastructure" patch goes in}}<br />
<br />
{{patch|3f0b79eb0810310436w360f0afdy76ff1499b177ce0d@mail.gmail.com|Synchronous log-shipping replication|Masao Fujii|reviewers=Heikki Linnakangas, Simon Riggs}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811040404r799d3170v5bb9f201000f1771@mail.gmail.com|signal handling patch v2}} here}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811050617o3237130awb4aec1d3a2daacab@mail.gmail.com|walsender process patch v1}} here}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811140215nd605e4u5ef56aee2ca6afea@mail.gmail.com|Synch Rep patch v2}} here}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811171908q2434a0bfrda0964987bb1a83a@mail.gmail.com|Synch Rep patch v3}} here}}<br />
{{comment|Dave Page|Heikki reports he is yet to review latest version. Is going to look at signal handling part, and commit first if OK 2008-11-27}}<br />
{{comment|fujii|Synch Rep patch v4 {{messageLink|3f0b79eb0811271845l4a8e4a20ga519aefc2a4d5162@mail.gmail.com|here}}}}<br />
{{comment|Dave Page|Simon reports his review is ongoing 2008-11-27}}<br />
{{comment|sriggs| {{messageLink|1228131740.20796.294.camel@hp_dx2400_1|First Thoughts on Code}}}}<br />
{{comment|fujii|I illustrated the architecture {{messageLink|3f0b79eb0812030437u4f9f56b3p6e78208b86a0dfb5@mail.gmail.com|here}}}}<br />
{{comment|fujii|The latest signal handling patch is {{messageLink|3f0b79eb0812082033o4dbbfd5dy1c0a605b3dd05e80@mail.gmail.com|here}}}}<br />
{{comment|CM|Dec. 14 status: still active discussion about order of operations}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Upgrade-in-place and related issues === <br />
<br />
{{patch|49380BDD.1000903@sun.com|pg_upgrade script for 8.3->8.4|Zdenek Kotala|reviewers=Greg Smith}}<br />
{{comment|CM|Dec. 14 status: needs more reviewers/testers. Recruiting}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== SQL language features ===<br />
<br />
{{patch|e08cc0400810270912u49a6ec83vc23984c01f368f76@mail.gmail.com|Window Functions|Hitoshi Harada|status=Ready for Committer|reviewers=Heikki Linnakangas, David Rowley, Tom Lane}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400810310721l22a6bb7kb6a300ce66443806@mail.gmail.com|here}}}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400811070746p43553f10s6bb09e98b7eafc3b@mail.gmail.com|here}}}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400811100548s1d31af73s888062c05c8512bd@mail.gmail.com|here}}, still some issues on {{messageLink|e08cc0400811100619w46a1b013x2051f6a8f2dad116@mail.gmail.com|ntile}} and {{messageLink|e08cc0400811100624o77744b15me1bc009b74d292c1@mail.gmail.com|nth_value}}}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400811120146r3c47b320g8aac5e22c05c8829@mail.gmail.com|here}}}}<br />
{{comment|Dave Page|David reports that he's waiting on an {{messageLink|492D1043.4080705@enterprisedb.com|updated patch}} from Heikki before continuing review 2008-11-26}}<br />
{{comment|Dave Page|Heikki reports he's not currently reviewing this, but has {{messageLink|492D1246.5070101@enterprisedb.com|refactored the code}} 2008-11-27}}<br />
{{comment|David Rowley|Patch is getting close. {{messageLink|839FB90FF49D4120B7107ED0D7B3E5B6@amd64|Comments}} 2008-12-05}}<br />
{{comment|David Rowley|Latest {{messageLink|e08cc0400812070641h37bfea91y9095f8c3366f5699@mail.gmail.com|patch}} 2008-12-07. Ready for core member review}}<br />
{{comment|CM|Dec 14 status: this patch appears to be ready for final committer check; what's the hold-up?}}<br />
<br />
{{patch|2849137C693B65CC8E86411C@imhotep.credativ.de|Automatic view update rules|status=Waiting on author|Bernd Helmle|reviewers=Unicron,Robert Haas}}<br />
{{comment|Bernd Helmle|New version with RETURNING support {{messageLink|94CF655A8D0DC7D5B4B81D8B@imhotep.credativ.de|here}}}}<br />
{{comment|Wolf Wei|it can be built and executed successfully, automatic insert/update/delete on view based on single table can work}} <br />
{{review|603c8f070811112006q906b3a6o59a66228b7fc997@mail.gmail.com|Robert Haas|fails regression tests, and a few other comments 2008-11-11}}<br />
{{comment|Robert Haas|author {{messageLink|EB911BE7EC3A7A599A379DEF@teje|plans to resubmit}} 2008-11-26}}<br />
{{comment|CM|dec. 15 status: Bernd says new patch RSN}}<br />
<br />
{{patch|1225543926.8122.14.camel@huvostro|Enable pl/python to return records based on multiple OUT params|Hannu Krosing|status=Waiting on author|reviewers=Unicron}}<br />
{{comment|Robert Haas|Hannu is {{messageLink|1225781532.7597.19.camel@huvostro|working on a new version}}}}<br />
{{comment|Robert Haas|oh, i guess Hannu actually {{messageLink|1227774392.8363.4.camel@huvostro|isn't working on a new version, but says the previous version is ready to go 2008-11-27}}}}<br />
{{comment|tgl|as I read the above-linked message, Hannu ''is'' still working on it}}<br />
{{comment|CM|Dec. 14 status: queried author 3 days ago. No update. Postpone?}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Indexes ===<br />
<br />
{{patch|490B07BA.6030109@sigaev.ru|GIN fast insert|Teodor Sigaev, Oleg Bartunov|reviewers=Jeff Davis}}<br />
{{comment|Robert Haas|some {{messageLink|492F04D9.5070404@enterprisedb.com|complaints from Heikki}} 2008-11-27}}<br />
{{comment|Teodor Sigaev|{{messageLink|4942A137.3000502@sigaev.ru|new version of GIN fast insert}}}}<br />
{{comment|CM|Dec. 14 status: queried reviewer for new review}}<br />
<br />
{{patch|490B3752.3010800@sigaev.ru|B-Tree emulation for GIN|status=Pending Review|Teodor Sigaev, Oleg Bartunov|reviewers=Jeff Davis,Ibrar Ahmed}}<br />
{{comment|Teodor Sigaev|{{messageLink|491B1888.9020903@sigaev.ru|new version of btree_gin}}}}<br />
{{comment|Oleg Bartunov|{{messageLink|Pine.LNX.4.64.0811191828050.7862@sn.sai.msu.ru|benefits of btree_gin}}}}<br />
{{comment|CM|Dec. 15 status: still pending review. Pinged Jeff, assigned 2nd reviewer.}}<br />
<br />
{{patch|20081101000154.GO27872@fune|On-disk bitmap indexes|status=Waiting on Author|Gabriele Bartolini, Gianni Ciolli|reviewers=Greg Stark (more welcome!)}}<br />
{{review|49130E72.1000803@sigaev.ru|Teodor Sigaev|several bugs}}<br />
{{comment|CM|Dev. 14 status: no update for 3 weeks. Queried authors.}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Performance ===<br />
<br />
{{patch|6EEA43D22289484890D119821101B1DF2C1683@exchange20.mercury.ad.ubc.ca|Improve Performance of Multi-Batch Hash Join for Skewed Data Sets|Ramon Lawrence/Bryce Cutt|reviewers=Joshua Tolley,Robert Haas}}<br />
{{comment|Joshua Tolley|[http://archives.postgresql.org/pgsql-hackers/2008-11/msg00286.php] reports backend crash}}<br />
{{comment|tgl|updated patch {{messageLink|1924d1180811051606w19aaf30du589e8ea10ea5534d@mail.gmail.com|here}}}}<br />
{{comment|tgl|some concerns {{messageLink|22901.1227228246@sss.pgh.pa.us|here}}}}<br />
{{comment|Josh Berkus|{{messageLink|6EEA43D22289484890D119821101B1DF2C1751@exchange20.mercury.ad.ubc.ca|new version as of Nov. 24}} }}<br />
{{comment|Dave Page|Josh reports performance testing is ongoing 2008-11-26}}<br />
{{comment|CM|Dec. 15 status: Tolley busy. Added Robert Haas as 2nd reviewer}}<br />
<br />
{{patch|87ljw5c0lx.fsf@oxford.xeocode.com|posix_fadvise|Gregory Stark|reviewers=Robert Haas|status=Pending Review}}<br />
{{review|603c8f070811131912l7054a0bex33a50850f1a43656@mail.gmail.com|Robert Haas|looks pretty clean, but needs some cleanup, maybe should be 2 patches}}<br />
{{comment|Dave Page|{{messageLink|87myfxhxh1.fsf@oxford.xeocode.com|Latest patch (v20)}}}}<br />
{{comment|Robert Haas|author still needs to {{messageLink|603c8f070811181955j367bdd82m712465740e7d36ea@mail.gmail.com|rip out some more posix_fallocate stuff}} and maybe {{messageLink|603c8f070811182001r3870122ep3f4ff69c1c93ef30@mail.gmail.com|fine-tune the docs}}}}<br />
{{comment|Josh Berkus|{{messageLink|87k5a6tmy7.fsf@oxford.xeocode.com|new version}} as of 12/11.}}<br />
{{comment|CM|Dec. 14 status: latest version needs review, perf. testing}}<br />
<br />
{{patch|a778a7260810280033n43f70d36x8c437eacf9a5461e@mail.gmail.com|Proposal of PITR performance improvement|Koichi Suzuki|status=Waiting on Author|reviewers=Simon Riggs}}<br />
{{comment|Robert Haas|{{messageLink|a778a7260811270404g49254640x8ed58b12b7c65d0b@mail.gmail.com|V2}} from patch author}}<br />
{{comment|CM|Dec. 14 Status: author is working on new version as of Dec. 11}}<br />
<br />
{{patch|36e682920811021349h7202bdecpd7a45c8a8038465e@mail.gmail.com|Hash Join-Filter Pruning using Bloom Filters|status=Waiting on Author|Jonah Harris|reviewers=Unicron}}<br />
{{comment|Uincron|can be built successfully, and find no questions after a view of code}}<br />
{{comment|CM|Dec. 14 status: still waiting on new patch from Jonah. Queried.}} <br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Improving admin experience ===<br />
<br />
{{patch|20081029183248.GE4331@alvh.no-ip.org|Block-level CRC checks|Alvaro Herrera|status=WIP}}<br />
{{comment|alvherre|{{messageLink|20081107191140.GE5507@alvh.no-ip.org|updated patch}} here}}<br />
{{comment|CM|Dec. 14 status: author has {{messageLink|20081214214409.GD6410@alvh.no-ip.org|halted work}}. Patch probably deferred to 8.5}}<br />
<br />
{{patch|1223379173.4747.145.camel@ebony.2ndQuadrant|Reducing some DDL Locks to ShareLock|status=Waiting on author|Simon Riggs|reviewers=Tom Lane}} <br />
{{comment|tgl|{{messageLink|1223404726.4747.249.camel@ebony.2ndQuadrant|v6 patch here}}}}<br />
{{comment|sriggs|agreed rework to implement pg_domain constraint, but the main patch still needs review}}<br />
{{comment|tgl|I think we'd decided to pass on the pg_constraint restructuring, at least for now}}<br />
{{comment|tgl|partially applied, what's left is {{messageLink|17459.1226279911@sss.pgh.pa.us|here}}}}<br />
{{comment|CM|Dec. 14 status: no activity since 12/2, queried author}}<br />
<br />
<br />
{{patch|a301bfd90810310750pf108c69x36499546f406650f@mail.gmail.com|Auto Partitioning Patch|Nikhil Sontakke|status=WIP|reviewers=Jaime Casanova}}<br />
{{comment|jcasanov|some comments {{messageLink|3073cc9b0811052047o4ebe24b4vd0ab24fd3095d342@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|a few more thoughts {{messageLink|603c8f070811262009v459d0701w151c16533d4ab947@mail.gmail.com|here}}}}<br />
{{comment|Josh Berkus|{{messageLink|493F1279.8010804@frogthinker.org|supplemental patch by Emmanuel}} }}<br />
{{comment|CM|Dec. 15 status: per Robert Haas, we lack a clear spec. Querying hackers on deferring to 8.5}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Contrib modules ===<br />
<br />
{{patch|20081011172450.3402.52131E4D@oss.ntt.co.jp|contrib/pg_stat_statements|Takahiro Itagaki|reviewers=Alex Hunsaker}}<br />
{{comment|Itagaki|updated version {{messageLink|20081202170106.A0EC.52131E4D@oss.ntt.co.jp|here}} (2008-12-02).}}<br />
{{comment|Josh Berkus|{{messageLink|20081212182754.BBA1.52131E4D@oss.ntt.co.jp|updated version of Dec. 12}} }}<br />
{{comment|CM|Dec. 14 status check: have asked Alex to re-review latest version}}<br />
<br />
{{patch|e4ccc24e0810222010p12bae2f4xa3a11cb2bc51bd89@mail.gmail.com|pg_standby support for compressed segments|Charles Duffy|reviewers=Simon Riggs}}<br />
{{comment|Simon Riggs|Deferring review for a few weeks until we get a better picture of streaming replication requirements for 8.4}}<br />
{{comment|CM|Dec. 14 status check: have asked if we're still waiting.}}<br />
<br />
{{patch|Pine.GSO.4.64.0811012101220.17619@westnet.com|Simple postgresql.conf wizard|Greg Smith|reviewers=Josh Berkus,Nathan Boley}}<br />
{{comment|Greg Smith|{{messageLink|Pine.GSO.4.64.0811090226060.26272@westnet.com|Updated V2}}}}<br />
{{comment|Greg Smith|{{messageLink|Pine.GSO.4.64.0811291403040.12885@westnet.com|Updated V3}}}}<br />
{{comment|CM|Dec. 14 Status Check: continued discussion. Lauched dev. project on pgFoundry}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Clients ===<br />
<br />
{{patch|48F04B7C.3080303@benedekl.tvnetwork.hu|pg_dump roles support|Benedek Laszlo|reviewers=Abhijit Menon-Sen|Status=Pending Review}}<br />
{{comment|alvherre|there's an {{messageLink|4912FA4E.1090000@benedekl.tvnetwork.hu|updated patch}}, and some extra {{messageLink|20081107202000.GG5507@alvh.no-ip.org|comments}}}}<br />
{{comment|Josh Berkus|{{messageLink|491CB8B8.3060706@benedekl.tvnetwork.hu|new version of Nov. 16}} }}<br />
{{comment|CM|Dec. 14 Status Check: assigned reviewer for new version}}<br />
<br />
{{patch|490878AC.1@dunslane.net|parallel restore|status=WIP|Andrew Dunstan|reviewers=Kenneth Marshall}}<br />
{{comment|Josh Berkus|{{messageLink|49453ECC.5030006@dunslane.net|new version}} which works with windows}}<br />
{{comment|CM|Dec. 14 Status check: need reviewer for Windows code}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Miscellaneous ===<br />
<br />
{{patch|03c301c91737$be5a2a30$0e01a8c0@IBMC9A0F63B40D|Solve a problem of LC_TIME of windows|Hiroshi Saito}}<br />
{{comment|mha|Even newer version {{messageLink|492AA5CD.8050001@hagander.net|here}}}}<br />
{{comment|itagaki|a new version of the patch {{messageLink|20081125173024.7B45.52131E4D@oss.ntt.co.jp|here}}}}<br />
{{comment|CM|Dec. 14 Status: looking for reviewer for new version}}<br />
<br />
{{patch|48F53EC0.3020004@timbira.com|autovacuum and reloption|Euler Taveira de Oliveira|reviewers=Alvaro Herrera,Abhijit Menon-Sen}}<br />
{{comment|alvherre|{{messageLink|4938A37E.9080301@timbira.com|new version}}, various fixes}}<br />
{{comment|CM|Dec. 14 Status: still waiting on Alvaro review; assigned 2nd reviewer}}<br />
<br />
{{patch|49097338.2070700@gmail.com|SQL/MED compatible connection manager|Martin Pihlak|reviewers=Peter Eisentraut}}<br />
{{comment|Martin Pihlak|Updated patch {{messageLink|4946B621.5060504@gmail.com|here}}}}<br />
{{comment|CM|Dec. 14 Status: waiting on new patch from Dec. 12 feedback}}<br />
<br />
{{patch|20081029164000.GL27466@fetter.org|pre-MED|David Fetter|reviewers=Alex Hunsaker|status=Waiting on author}}<br />
{{comment|David Fetter|Updated patch {{messageLink|20081031144852.GF15545@fetter.org|here}}}}<br />
{{review|34d269d40811031902p1d73d177w9f2e721ae169e8be@mail.gmail.com|alexhun|few questions and tgl had some constructive {{messageLink|24867.1225819435@sss.pgh.pa.us|comments}}}}<br />
{{comment|CM|Dec. 14 Status: no activity in 20 days, contacted author}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Committed patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|20080803.114711.73374027.t-ishii@sraoss.co.jp|Common Table Expressions|Yoshiyuki Asaba|status=Committed 2008-10-04|reviewers=Jeff Davis}}<br />
{{comment|David Fetter|README is {{messageLink|20080818.163852.105172778.t-ishii@sraoss.co.jp|here.}}}}<br />
{{comment|David Fetter|Git repository is [http://git.postgresql.org/git/~davidfetter/cte/.git here.]}}<br />
{{comment|David Fetter|[[CTEReadme]]}}<br />
{{comment|David Fetter|[[CTESQLStandard| Fair Use from the draft SQL:2008 standard (WIP)]]}}<br />
{{review|13449.1221589943@sss.pgh.pa.us|tgl|needs a good bit of work yet}}<br />
<br />
{{patch|Pine.GSO.4.64.0809152349440.19910@westnet.com|Add default_val to pg_settings|status=Committed 2008-10-06|Greg Smith|reviewers=Simon Riggs,Magnus Hagander}}<br />
<br />
{{patch|20081016102603.897D.52131E4D@oss.ntt.co.jp|Noisy _dosmaperror|status=Committed 2008-10-16|Takahiro Itagaki|reviewers=Tom Lane}}<br />
<br />
{{patch|b4e5ce320810151918g2acf69ebh9f80f4f2e1c203a0@mail.gmail.com|Memory leak on hashed agg rescan|status=Committed 2008-10-16|Neil Conway|reviewers=Tom Lane}}<br />
{{review|10455.1224160007@sss.pgh.pa.us|Tom Lane|move some logic to separate function}}<br />
<br />
{{patch|1223383838.4747.154.camel@ebony.2ndQuadrant|Atomic subtransaction commit|status=Committed 2008-10-20|Simon Riggs|reviewers=Alvaro Herrera}} <br />
<br />
{{patch|3327.1224535092@sss.pgh.pa.us|add placeholder variables to planner|status=Committed 2008-10-22|Tom Lane}}<br />
<br />
{{patch|48E271C5.7010907@hagander.net|pg_hba options parsing|status=Committed 2008-10-23|Magnus Hagander|reviewers=Bruce Momjian}}<br />
{{comment|Robert Haas|{{messageLink|48F0DE8B.8030004@hagander.net|updated patch}}}}<br />
<br />
{{patch|48FC3994.8040809@hagander.net|libpq ssl -> clear fallback looses error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905D22D.9040001@hagander.net|better hba parsing error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905A1DE.5030102@hagander.net|remove crypt authentication|status=Committed 2008-10-28|Magnus Hagander}}<br />
<br />
{{patch|4905F515.3020208@gmx.net|Unicode escapes in literals|status=Committed 2008-10-29|Peter Eisentraut}}<br />
<br />
{{patch|490A138E.80100@enterprisedb.com|User defined I/O conversion casts|status=Committed 2008-10-31|Heikki Linnakangas}}<br />
<br />
{{patch|49085327.5010608@enterprisedb.com|Updating FSM on recovery|status=Committed 2008-10-31|Heikki Linnakangas}}<br />
<br />
{{patch|Pine.BSO.4.64.0810271955030.28764@leary.csoft.net|use new heap_(form/deform/modify)_tuple API|Kris Jurka|reviewers=Zdenek Kotala|status=Committed 2008-11-01}}<br />
{{comment|Zdenek Kotala| It seems OK. Needs apply also {{messageLink|Pine.BSO.4.64.0810281721500.6833@leary.csoft.net|pfree patch.}}}}<br />
<br />
{{patch|Pine.BSO.4.64.0810281622240.9851@leary.csoft.net|don't use MAKE_PTR/OFFSET for shmem pointers|Kris Jurka|reviewers=Tom Lane|status=Committed 2008-11-02}}<br />
<br />
{{patch|48C181D4.8030807@gmail.com|reducing statistics write overhead|Martin Pihlak|reviewers=Tom Lane|status=Committed 2008-11-02}}<br />
{{comment|Martin Pihlak|Latest patch {{messageLink|48C594D8.6050504@gmail.com|here}}}}<br />
<br />
{{patch|37ed240d0809030015u73b65b66v70fd76741317c6f5@mail.gmail.com|pg_typeof()|Brendan Jurd|reviewers=Kurt Harriman|status=Committed 2008-11-03}}<br />
{{comment|Kurt Harriman|{{messageLink|http://archives.postgresql.org/pgsql-hackers/2008-11/msg00080.php|Updated patch}} is ready to commit if there is no objection}}<br />
<br />
{{patch|Pine.BSO.4.64.0810081931240.11647@leary.csoft.net|Fixes for psql describeOneTableDetails|Kris Jurka|reviewers=Tom Lane|status=Committed 2008-11-03}}<br />
<br />
{{patch|48E22CF5.4050503@sun.com|PageGetTempPage cleanup |Zdenek Kotala|reviewers=Tom Lane|status=Committed 2008-11-03}}<br />
{{comment|Zdenek Kotala|Original discussion {{messageLink|4938.1217862947@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|603c8f070810092009s1312d30bxc854cdfb5d9fed7e@mail.gmail.com|Allow the UUID type to accept non-standard formats|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-03}}<br />
<br />
{{patch|603c8f070810101937n776c1e7cvd6a12345b0bbda28@mail.gmail.com|array_ndims|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-04}}<br />
<br />
{{patch|603c8f070810282045g7fa6bdf9p53f03114d49643d7@mail.gmail.com|bulk inserts - keep most recent page pinned|Robert Haas|reviewers=Tom Lane|status=Committed 2008-11-06}}<br />
{{comment|Robert Haas|based on work by Simon Riggs: [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01080.php original idea],[http://archives.postgresql.org/pgsql-patches/2008-02/msg00140.php original patch], [http://archives.postgresql.org/pgsql-patches/2008-02/msg00154.php Tom Lane's comments]}}<br />
{{comment|Robert Haas|Tom's comments on my [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01276.php design proposal] are {{messageLink|17996.1225049097@sss.pgh.pa.us|here}}}}<br />
{{comment|Robert Haas|patch {{messageLink|603c8f070811011023n202aea33w4da13b7d14f74134@mail.gmail.com|v2}}, adjusting for Heikki's changes to the ReadBuffer interface}}<br />
<br />
{{patch|490394B7.6090503@lelarge.info|ALTER DATABASE SET TABLESPACE Statement|Guillaume Lelarge|reviewers=Bernd Helmle|status=Committed 2008-11-07}}<br />
{{comment|Bernd Helmle|Syntax discussion and updated version {{messageLink|C0F6602797884925406AB88F@imhotep.credativ.de|here}}}}<br />
{{comment|Guillaume Lelarge|Updated version with SET syntax {{messageLink|4910E46E.4010000@lelarge.info|here}}}}<br />
{{comment|Bernd Helmle|Updated version from Guillaume {{messageLink|4912C88A.2070808@lelarge.info|here}}}}<br />
{{comment|Guillaume Lelarge|Updated version {{messageLink|49140181.3000903@lelarge.info|here}}}}<br />
<br />
{{patch|0BD2E4E9-AF5A-4B4F-B546-027424EE8FAD@kineticode.com|Tests citext casts|David Wheeler|reviewers=<br />
Kenneth Marshall|status=Committed 2008-11-07}}<br />
<br />
{{patch|48D15471.6080305@cheapcomplexdevices.com|SQL Standard Interval output and IntervalStyle GUC|Ron Mayer|status=Committed 2008-11-08|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|Early updates {{messageLink|48D52E48.406@cheapcomplexdevices.com|here}}, {{messageLink|48E49BDC.4090402@cheapcomplexdevices.com|here}}, and [http://0ape.com/postgres_interval_patches/ here]. Mostly related to GUC changes.}}<br />
{{review|37ed240d0811032122u56db1959h91f53bbb9733c90d@mail.gmail.com|BJ|Bug in output, stylistic suggestions}}<br />
{{comment|the mailing list|Feedback from {{messageLink|19477.1225814409@sss.pgh.pa.us|Tom L}} and {{messageLink|49101C94.EE98.0025.0@wicourts.gov|Kevin G}} about mixed-sign intervals}}<br />
{{comment|Ron Mayer|Updated patch {{messageLink|4910B1DB.4000000.cheapcomplexdevices@com|here}} to fix -12:01:-30 bug and style suggestions from the review and to attempt to address feedback about mixed-sign intervals with doc updates.}}<br />
{{review|37ed240d0811042102q78df5b86t2ff2092a75d371d7@mail.gmail.com|BJ|One last typo in docs but otherwise all good; review complete}}<br />
{{review|28915.1226109473@sss.pgh.pa.us|Tom L|Tom pointed out issues with pg_dump and restore into databases with a different interval style}}<br />
{{comment|Ron Mayer|{{messageLink|4915AC0A.9070608@cheapcomplexdevices.com|Speculating}} if an analogy with standard_conforming_strings applies to how we can handle dump/restore.}}<br />
<br />
{{patch|48E4A30C.3000503@cheapcomplexdevices.com|status=Committed 2008-11-10|ISO 8601 interval literal input and output|Ron Mayer|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|The initial (2003) version of this patch along with a thread which explains the feature a bit more can be found [http://archives.postgresql.org/pgsql-patches/2003-09/msg00103.php here].}}<br />
{{comment|Robert Haas|{{messageLink|490BA342.7010300@cheapcomplexdevices.com|latest version}}}}<br />
{{review|37ed240d0811050750v11726fd1of441646f87b583da@mail.gmail.com|BJ|Code style and documentation suggestions}}<br />
{{comment|Ron Mayer|Update here [http://0ape.com/postgres_interval_patches/ here] that fixes style & docs; as well as a bug where the ISO8601 spec wasn't quite followed (an optional field was treated as required by previous patches).}}<br />
{{review|37ed240d0811062058n752c3880kb04feb85e355b524@mail.gmail.com|BJ|Query behaviour of 'P0001', final doc cleanup suggestions}}<br />
{{comment|Ron Mayer|Update here [http://0ape.com/postgres_interval_patches/ here] that fixes 'P0001' and updated docs.}}<br />
<br />
{{patch|48CEDE68.7090501@cheapcomplexdevices.com|Interval rounding consistency|Ron Mayer|status=Committed 2008-11-11|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|Patch 3 [http://0ape.com/postgres_interval_patches/ here] refactors the interval code to remove much of the copy&paste in DecodeInterval and EncodeInterval with the side effect of making interval rounding more consistent between styles. This patch applies on top of the IntervalStyle patch and the ISO 8601 Interval patch.}}<br />
{{review|37ed240d0811101214l4d4427d8jcdf64486fd254db9@mail.gmail.com|BJ|Code style cleanups, a couple queries}}<br />
<br />
{{patch|20952F54-6730-49D8-99A3-1834697790B5@decibel.org|array_length|Jim C. Nasby|reviewers=Peter Eisentraut|status=Committed 2008-11-12}}<br />
{{comment|Robert Haas|I have {{messageLink|603c8f070811062006q4f20b2bq179d4d2ffec65690@mail.gmail.com|reimplemented this in C}}}}<br />
<br />
{{patch|48FC7E84.3080702@hagander.net|SSL cleanups/hostname verification|Magnus Hagander|reviewers=Alex Hunsaker|status=Committed 2008-11-13}}<br />
{{comment|Magnus|{{messageLink|491985B1.3090300@hagander.net|Updated patch}}}}<br />
{{review|34d269d40811120805i16400cfck972b2aebac6eba44@mail.gmail.com|alexhun|looks good}}<br />
<br />
{{patch|603c8f070810151933p445978b3td481a5422a2aebf4@mail.gmail.com|array_agg/array_accum|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-13}}<br />
{{comment|Robert Haas|{{messageLink|1225045937.4434.21.camel@localhost.localdomain|another version}} and {{messageLink|1225682527.1375.150.camel@jdavis|another one}} from Jeff Davis}}<br />
<br />
{{patch|20081009165157.9BE4.52131E4D@oss.ntt.co.jp|contrib/auto_explain|status=Committed 2008-11-18|Takahiro Itagaki|reviewers=Jeff Davis}}<br />
{{comment|Jeff|{{messageLink|1226426084.3002.76.camel@jdavis|minor documentation edits by reviewer}}}}<br />
{{comment|Itagaki|{{messageLink|20081118114842.ED3F.52131E4D@oss.ntt.co.jp|latest patch versions}}}}<br />
<br />
{{patch|49009D67.4040202@hagander.net|clientcert option for pg_hba|Magnus Hagander|reviewers=Unicron, Alex Hunsaker|status=Committed 2008-11-20}}<br />
{{review|34d269d40811151420p24f80a5i206febbb2ecd0831@mail.gmail.com|alexhun|Quick review, new patch looks good}}<br />
<br />
{{patch|491C1E2D.8060905@hagander.net|client certificate authentication|Magnus Hagander|reviewers=Alex Hunsaker|status=Committed 2008-11-20}}<br />
{{comment|Magnus|Dependant on the "clientcert option for pg_hba" patch}}<br />
{{review|34d269d40811151600jb0dce03mf5d03f4829bbf59c@mail.gmail.comm|alexhun|Looks good}}<br />
<br />
{{patch|4909726F.8000800@gmx.net|TABLE command|Peter Eisentraut|status=Committed 2008-11-20|reviewers=Unicron, Robert Haas}}<br />
{{comment|Unicron|Patch {{messageLink|850603.14426.qm@web62408.mail.re1.yahoo.com|works per specification}}}}<br />
{{review|603c8f070811081050k79926d12x6547ae72abaa41af@mail.gmail.com|Robert Haas|wrong non-terminal, needs doc and psql updates}}<br />
<br />
{{patch|c2ee6dbd0810100553gd328275ue2eb6e14bee70a8@mail.gmail.com|adding VERBOSE option to CLUSTER|Jim Cox|status=Committed 2008-11-24|reviewers=Peter Eisentraut}}<br />
<br />
{{patch|49076F39.1080502@hagander.net|regexp support in usermaps|Magnus Hagander|reviewers=Gianni Ciolli|status=Committed 2008-11-28}}<br />
{{comment|Magnus|{{messageLink|49198FA5.6020206@hagander.net|Updated patch}}}}<br />
{{comment|Gianni Ciolli|The second version looks like ready to me.}}<br />
<br />
{{patch|1223472186.4747.301.camel@ebony.2ndQuadrant|pg_stop_backup wait bug fix|Simon Riggs|reviewers=Ibrar Ahmed, Heikki Linnakangas|status=Committed 2008-12-03}}<br />
{{comment|Robert Haas|sriggs extracted this from recovery infrastructure patch per {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's suggestion}}}}<br />
{{comment|Robert Haas|heikki has {{messageLink|493596CE.6040408@enterprisedb.com|an updated version}}}}<br />
<br />
{{patch|4905AE17.7090305@enterprisedb.com|Visibility map, partial vacuums|status=Waiting on author|Heikki Linnakangas|reviewers=Tom Lane|status=Committed 2008-12-03}}<br />
{{comment|tgl|updated patch {{messageLink|4925664C.3090605@enterprisedb.com|here}}}}<br />
{{comment|tgl|Nearly committable, some nits {{messageLink|26361.1227467112@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|200810271936.m9RJaGW09544@momjian.us|libpq callback unregistration|Bruce Momjian|reviewers=Magnus Hagander|status=Committed 2008-12-03}}<br />
{{comment|Magnus|Needs more work, comments {{messageLink|490EEF2D.2050703@hagander.net|here}}}}<br />
{{comment|alvherre|Bruce posted a {{messageLink|200811050502.mA552TJ20677@momjian.us|new version}}, but it still {{messageLink|20081107201029.GF5507@alvh.no-ip.org|needs some work}}}}<br />
{{comment|Magnus|Updated {{messageLink|200811210002.mAL02gQ26376@momjian.us|patch}}}}<br />
<br />
{{patch|162867790810260428p56d16352qa1ec5c4c5330f25c@mail.gmail.com|default values for function's parameters|Pavel Stehule|reviewers=Peter Eisentraut|status=Committed 2008-12-04}}<br />
{{comment|Pavel Stehule| fix known bugs, currently only doc should be finished}}<br />
{{comment|Peter Eisentraut|data type for catalog entries needs change}}<br />
{{comment|Robert Haas|Pavel just posted {{messageLink|162867790811261414w4a22e9edj4445d8da47794377@mail.gmail.com|a new version}} 2008-11-26}}<br />
<br />
{{patch|603c8f070808070503jd7be083kcce3e16345affb08@mail.gmail.com|add columns via CREATE OR REPLACE VIEW|Robert Haas|reviewers=Bernd Helmle|status=Committed 2008-12-06}}<br />
{{comment|Robert Haas|some further justification of the proposed design {{messageLink|603c8f070808070956t1ab98dcdr933575eb096e4c28@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|questions about how to move forward {{messageLink|603c8f070810031839y7ce9a852o86effbab9fd6dd9b@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|a {{messageLink|482096EC.3000805@dunslane.net|similar feature request}} from Andrew Dunstan}}<br />
{{comment|Dave Page|Bernd reports he has found some issues and expects to report to the list/Robert today 2008-11-27}}<br />
{{comment|Bernd Helmle|Found a problem when using domains with constraints {{messageLink|EC7E967B3307C67C3DD714D1@teje|here}}}}<br />
{{comment|Robert Haas|new version {{messageLink|603c8f070812011748p541f8593k57737d04554c15d5@mail.gmail.com|here}} 2008-12-01}}<br />
<br />
{{patch|20080801203157.GL4321@alvh.no-ip.org|Client SSL key/certificate/etc file name specification|Mark Woodward, Alvaro Herrera, Magnus Hagander|reviewers=Magnus Hagander, Alex Hunsaker|status=Committed 2008-12-15}}<br />
{{comment|Magnus|Picked up from having been dropped from a previous commit fest, this is the latest updated version}}<br />
{{comment|Magnus|{{messageLink|34d269d40811202107q489e2be0h771762398dd9fcdb@mail.gmail.com|Updated patch}} 2008-11-20}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Returned with Feedback ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|1225010283.21241.33.camel@localhost.localdomain|new correlation metric|Jeff Davis|reviewers=Brendan Jurd|status=Pending rework}}<br />
<br />
{{patch|490B7C1B.8050408@sun.com|In-place online upgrade|status=Removed from queue per author|Zdenek Kotala|reviewers=Robert Haas}}<br />
{{comment|Zdenek Kotala|This patch requires "htup and bufpage API clean up" and "HeapTuple version extension" patches. Git repository is [http://git.postgresql.org here] }}<br />
{{review|603c8f070811022022x582a9cbdp60798a6b87910edf@mail.gmail.com|Robert Haas|preliminary comments, still need a clean diff}}<br />
<br />
{{patch|48F1FC7E.1060406@sun.com|Extending pg_class info + more flexible TOAST chunk size|Zdenek Kotala|reviewers=Robert Haas|status=Removed from queue per author}}<br />
{{comment|tgl|seems it'd be better to make TOAST chunks work like {{messageLink|490AB654.6040409@enterprisedb.com|this}}}}<br />
{{comment|tgl|Alvaro has a {{messageLink|20081117211021.GN4291@alvh.no-ip.org|draft patch}} for that}}<br />
<br />
{{patch|4909B326.507@enterprisedb.com|Optimizing COPY with memchr()|Heikki Linnakangas|status=WIP|reviewers=Robert Haas}}<br />
{{comment|tgl|does this really need any more review at this point?}}<br />
{{comment|Robert Haas|asked author for {{messageLink|603c8f070811081745v410d2ff5o4bd107d7fbb440f3@mail.gmail.com|a status update}}}}<br />
{{comment|Robert Haas|will {{messageLink|491A1266.9090305@enterprisedb.com|not be ready for 8.4}}}}<br />
<br />
{{patch|162867790810170316l4eeecb0bq321dd771f8f4e661@mail.gmail.com|grouping sets|status=WIP|Pavel Stehule|reviewers=Ibrar Ahmed}}<br />
{{comment|Pavel Stehule| doc and notes [[Grouping Sets]]}}<br />
{{comment|Pavel Stehule| actualised patch http://www.pgsql.cz/patches/gsets.diff.gz}}<br />
{{comment|tgl|Pavel says this is {{messageLink|162867790811240316y52227d88xe53527399b329e05@mail.gmail.com|not intended}} for 8.4}}<br />
{{comment|Ibrar| Review {{messageLink|162867790811240316y52227d88xe53527399b329e05@mail.gmail.com|complete}}}}<br />
<br />
{{patch|490B102A.10106@gmx.net|Distinct types|Peter Eisentraut|status=WIP}}<br />
{{comment|Bernd Helmle|Patch needs further work regarding {{messageLink|17750.1225571886@sss.pgh.pa.us|indexing}}}}<br />
{{comment|tgl|I don't think the {{messageLink|21942.1226084284@sss.pgh.pa.us|type-system behavior}} has been thought through properly}}<br />
<br />
{{patch|49086E4C.9030602@sun.com|htup and bufpage API clean up|Zdenek Kotala|reviewers=Robert Haas|status=Waiting on author}}<br />
{{comment|Zdenek Kotala|New version is {{messageLink|490875FA.4020709@sun.com|here}}}}<br />
{{comment|Robert Haas|author {{messageLink|492D10DE.3020108@sun.com|plans to resubmit}} but it's {{messageLink|492E8AC1.6020808@sun.com|not his top priority}} 2008-11-26}}<br />
{{comment|CM|Dec. 15: per Zdenek, this will not get done for 8.4; he is working on page reservation instead. Moving to returned queue.}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Rejected Patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|f205bb120810280833x340324d3m19a4f8aa65d822b@mail.gmail.com|FAQ_Solaris 1.28 to spanish|Emanuel CALVO FRANCO|reviewers=Peter Eisentraut||status=Rejected}}<br />
{{comment|Peter Eisentraut|We are not ready to maintain translations of this type of material.}}<br />
<br />
{{patch|4909DFCE.1000702@sun.com|HeapTuple version extension + code cleanup|Zdenek Kotala|reviewers=Robert Haas|status=Rejected}}<br />
{{review|603c8f070811031822q7d3b33f7x8576b7028f498cc4@mail.gmail.com|Robert Haas|proposed API seems too costly and fragile}}<br />
{{comment|Robert Haas|I think we have consensus that {{messageLink|10341.1225762057@sss.pgh.pa.us|this is not the right approach}}}}<br />
<br />
{{patch|48EFA13C.2060407@frogthinker.org|Prepared transactions and temp tables|status=Rejected|Emmanuel Cecchet|reviewers=Heikki Linnakangas}}<br />
{{comment|tgl|new patch version {{messageLink|4914CD14.2060608@frogthinker.org|here}}}}<br />
{{comment|Robert Haas|{{messageLink|4934A4E0.8080208@frogthinker.org|new patch version}} from Emmanuel, who says he needs feedback from Heikki before proceeding further 2008-12-01}}<br />
{{comment|Heikki|I think we need to take a completely {{messageLink|492543D5.9050904@enterprisedb.com|different approach}}.}}<br />
<br />
{{patch|BLU110-W38CE0A22D467A8C3D9736CFF540@phx.gbl|Support PLUGINS lines in Makefiles, similar to MODULES|Asif Naeem|reviewers=Robert Haas|status=Rejected}}<br />
{{comment|Dave Page|This doesn't work with the edb-debugger plugin, which is the only such plugin around AFAIK. It needs to ignore comments on the PLUGINS line, and handle multiple targets (plugin_debugger, pldbgapi, targetinfo etc). Not sure if we want that complexity though.}}<br />
{{comment|Heikki|Unix-makefile version: {{messageLink|BLU110-W57823CEB7DC113354471EFF3B0@phx.gbl|here}}}}<br />
{{comment|Robert Haas|waiting for response to {{messageLink|603c8f070811280542q61ced9fdu5525ebb1234b2bf0@mail.gmail.com|email sent to author}} 2008-11-28}}<br />
{{comment|Robert Haas|no response from author 2008-12-05}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Round Robin Reviewers ==<br />
<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="width: 60%; border-collapse: collapse; border: 1px solid #ccc; font-size: 90%;"<br />
|- style="background: #eee;"<br />
! width="30%" | Name<br />
!Status<br />
!Reviewing<br />
!Completed<br />
|-<br />
|Brendan Jurd || Available || 0 || 4<br />
|-<br />
|Jaime Casanova || Available || 1 || 1<br />
|-<br />
|Stephen Frost || Available 11/15 || 0 || 0<br />
|-<br />
|Jeff Davis || Available || 2 || 1<br />
|-<br />
|Greg Stark || Unknown || 1 || 0<br />
|-<br />
|Abhijit Menon-Sen || Unknown || 0 || 0<br />
|-<br />
|Alex Hunsaker || Available || 1 || 1<br />
|-<br />
|Markus Wanner || Cherry-picking || 1 || 0<br />
|-<br />
|Ibrar Ahmed || Available || 1 || 0<br />
|-<br />
|D'Arcy Cain || Unknown || 0 || 0<br />
|-<br />
|Kenneth Marshall || Available || 1 || 1<br />
|-<br />
|Robert Haas || Available || 0 || 7<br />
|-<br />
|Matthew Wetmore || Out-of-contact || 0 || 0<br />
|-<br />
|Gianni Colli || Available || 1 || 0<br />
|-<br />
|"Unicron" || Available || 1 || 4<br />
|-<br />
|Pavan Deolasee || Available || 1 || 0<br />
|}</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-11&diff=3801CommitFest 2008-112008-12-11T07:19:38Z<p>Martin.pihlak: /* Miscellaneous */</p>
<hr />
<div>__TOC__<br />
<br />
This is the page for the CommitFest starting '''2008 November'''.<br />
<br />
Managers for this CommitFest are Josh Berkus (josh-at-agliodbs-com) and Dave Page (dpage-at-pgadmin-org).<br />
<br />
{{CommitFestCurrent}}<br />
<br />
== Pending patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
|-<br />
| colspan="4" |<br />
=== SE-PostgreSQL and related ===<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei|reviewers=Tom Lane, Simon Riggs, Bruce Momjian}}<br />
{{comment|KaiGai|[[SEPostgreSQL]] is a draft of comprehensive document}}<br />
{{comment|KaiGai|{{messageLink|4938F7FA.60805@ak.jp.nec.com|The latest patches to be reviewed (r1280), as of Dec. 5}}}}<br />
<br />
{{patch|20080901063855.GJ16005@tamriel.snowman.net|Column-level Permissions|Stephen Frost|status=Waiting on Author|reviewers=Markus Wanner,Alvaro Herrera}}<br />
{{comment|Stephen Frost|Updated patch {{messageLink|20080902221823.GL16005@tamriel.snowman.net|here}}}}<br />
{{review|48DB48AC.5010400@bluegap.ch|Markus Wanner|Awaiting updated patch.}}<br />
{{comment|Stephen Frost|Updated patch, again, {{messageLink|20081102034517.GR4452@tamriel.snowman.net|here}}}}<br />
{{comment|Stephen Frost|Updated patch, fixes case where unprivileged user can get row count, {{messageLink|20081102131332.GU4452@tamriel.snowman.net|here}}}}<br />
{{comment|alvherre|{{messageLink|20081114135033.GD3830@alvh.no-ip.org|Updated patch}}}}<br />
{{comment|Robert Haas|Stephen Frost agreed to make {{messageLink|20081125210308.GD4452@tamriel.snowman.net|some minor changes}} 2008-11-25}}<br />
|-<br />
| colspan="4" |<br />
<br />
=== Recovery, Replication, Hot Standby ===<br />
<br />
{{patch|1220213074.4371.173.camel@ebony.2ndQuadrant|Infrastructure changes for recovery|status=Waiting on author|Simon Riggs|reviewers=Tom Lane, Heikki Linnakangas}} <br />
{{comment|sriggs| important patch for other work}}<br />
{{comment|Robert Haas|{{messageLink|1223472898.4747.310.camel@ebony.2ndQuadrant|patch v9}} here, in response to {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's review}}}}<br />
{{comment|sriggs|some issues overlooked, fixed as part of Hot Standby patch only at present}}<br />
{{comment|sriggs|do we want this split out again as a separate patch for easier review?}}<br />
{{comment|Robert Haas|looks like the consensus is that this should be {{messageLink|2e78013d0811200149t29173598m5eb70f62c1dc02d4@mail.gmail.com|split back out as a separate patch}}}}<br />
{{comment|Dave Page|Heikki reports he is waiting on Simon for a split set of patches 2008-11-27}}<br />
<br />
{{patch|1225557138.3971.673.camel@ebony.2ndQuadrant|Hot Standby - queries during archive recovery|status=Pending Review|Simon Riggs|reviewers=Pavan Deolasee, Koichi Suzuki}}<br />
{{comment|sriggs| v5d now available, fixing all Mark's reported issues. Main parts are fully reviewable}}<br />
{{comment|sriggs| Wiki contains dynamically updated list of outstanding items [[Hot_Standby]] }}<br />
<br />
{{patch|1220174867.4371.107.camel@ebony.2ndQuadrant|rmgr hooks and contrib/rmgr_hook|status=Waiting on dependencies|Simon Riggs}} <br />
{{comment|sriggs| deferrable, if required}}<br />
{{comment|tgl|I think the plan is for this to wait till "infrastructure" patch goes in}}<br />
<br />
{{patch|3f0b79eb0810310436w360f0afdy76ff1499b177ce0d@mail.gmail.com|Synchronous log-shipping replication|Masao Fujii|reviewers=Heikki Linnakangas, Simon Riggs}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811040404r799d3170v5bb9f201000f1771@mail.gmail.com|signal handling patch v2}} here}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811050617o3237130awb4aec1d3a2daacab@mail.gmail.com|walsender process patch v1}} here}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811140215nd605e4u5ef56aee2ca6afea@mail.gmail.com|Synch Rep patch v2}} here}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811171908q2434a0bfrda0964987bb1a83a@mail.gmail.com|Synch Rep patch v3}} here}}<br />
{{comment|Dave Page|Heikki reports he is yet to review latest version. Is going to look at signal handling part, and commit first if OK 2008-11-27}}<br />
{{comment|fujii|Synch Rep patch v4 {{messageLink|3f0b79eb0811271845l4a8e4a20ga519aefc2a4d5162@mail.gmail.com|here}}}}<br />
{{comment|Dave Page|Simon reports his review is ongoing 2008-11-27}}<br />
{{comment|sriggs| {{messageLink|1228131740.20796.294.camel@hp_dx2400_1|First Thoughts on Code}}}}<br />
{{comment|fujii|I illustrated the architecture {{messageLink|3f0b79eb0812030437u4f9f56b3p6e78208b86a0dfb5@mail.gmail.com|here}}}}<br />
{{comment|fujii|The latest signal handling patch is {{messageLink|3f0b79eb0812082033o4dbbfd5dy1c0a605b3dd05e80@mail.gmail.com|here}}}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Upgrade-in-place and related issues === <br />
<br />
{{patch|49086E4C.9030602@sun.com|htup and bufpage API clean up|Zdenek Kotala|reviewers=Robert Haas|status=Waiting on author}}<br />
{{comment|Zdenek Kotala|New version is {{messageLink|490875FA.4020709@sun.com|here}}}}<br />
{{comment|Robert Haas|author {{messageLink|492D10DE.3020108@sun.com|plans to resubmit}} but it's {{messageLink|492E8AC1.6020808@sun.com|not his top priority}} 2008-11-26}}<br />
<br />
{{patch|49380BDD.1000903@sun.com|pg_upgrade script for 8.3->8.4|Zdenek Kotala|reviewers=Greg Smith}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== SQL language features ===<br />
<br />
{{patch|e08cc0400810270912u49a6ec83vc23984c01f368f76@mail.gmail.com|Window Functions|Hitoshi Harada|reviewers=Heikki Linnakangas, David Rowley, Tom Lane}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400810310721l22a6bb7kb6a300ce66443806@mail.gmail.com|here}}}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400811070746p43553f10s6bb09e98b7eafc3b@mail.gmail.com|here}}}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400811100548s1d31af73s888062c05c8512bd@mail.gmail.com|here}}, still some issues on {{messageLink|e08cc0400811100619w46a1b013x2051f6a8f2dad116@mail.gmail.com|ntile}} and {{messageLink|e08cc0400811100624o77744b15me1bc009b74d292c1@mail.gmail.com|nth_value}}}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400811120146r3c47b320g8aac5e22c05c8829@mail.gmail.com|here}}}}<br />
{{comment|Dave Page|David reports that he's waiting on an {{messageLink|492D1043.4080705@enterprisedb.com|updated patch}} from Heikki before continuing review 2008-11-26}}<br />
{{comment|Dave Page|Heikki reports he's not currently reviewing this, but has {{messageLink|492D1246.5070101@enterprisedb.com|refactored the code}} 2008-11-27}}<br />
{{comment|David Rowley|Patch is getting close. {{messageLink|839FB90FF49D4120B7107ED0D7B3E5B6@amd64|Comments}} 2008-12-05}}<br />
{{comment|David Rowley|Latest {{messageLink|e08cc0400812070641h37bfea91y9095f8c3366f5699@mail.gmail.com|patch}} 2008-12-07. Ready for core member review}}<br />
<br />
{{patch|2849137C693B65CC8E86411C@imhotep.credativ.de|Automatic view update rules|status=Waiting on author|Bernd Helmle|reviewers=Unicron,Robert Haas}}<br />
{{comment|Bernd Helmle|New version with RETURNING support {{messageLink|94CF655A8D0DC7D5B4B81D8B@imhotep.credativ.de|here}}}}<br />
{{comment|Wolf Wei|it can be built and executed successfully, automatic insert/update/delete on view based on single table can work}} <br />
{{review|603c8f070811112006q906b3a6o59a66228b7fc997@mail.gmail.com|Robert Haas|fails regression tests, and a few other comments 2008-11-11}}<br />
{{comment|Robert Haas|author {{messageLink|EB911BE7EC3A7A599A379DEF@teje|plans to resubmit}} 2008-11-26}}<br />
<br />
{{patch|1225543926.8122.14.camel@huvostro|Enable pl/python to return records based on multiple OUT params|Hannu Krosing|status=Waiting on author|reviewers=Unicron}}<br />
{{comment|Robert Haas|Hannu is {{messageLink|1225781532.7597.19.camel@huvostro|working on a new version}}}}<br />
{{comment|Robert Haas|oh, i guess Hannu actually {{messageLink|1227774392.8363.4.camel@huvostro|isn't working on a new version, but says the previous version is ready to go 2008-11-27}}}}<br />
{{comment|tgl|as I read the above-linked message, Hannu ''is'' still working on it}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Indexes ===<br />
<br />
{{patch|490B07BA.6030109@sigaev.ru|GIN fast insert|Teodor Sigaev, Oleg Bartunov|reviewers=Jeff Davis}}<br />
{{comment|Robert Haas|some {{messageLink|492F04D9.5070404@enterprisedb.com|complaints from Heikki}} 2008-11-27}}<br />
<br />
{{patch|490B3752.3010800@sigaev.ru|B-Tree emulation for GIN|status=WIP|Teodor Sigaev, Oleg Bartunov|reviewers=Jeff Davis}}<br />
{{comment|Teodor Sigaev|{{messageLink|491B1888.9020903@sigaev.ru|new version of btree_gin}}}}<br />
{{comment|Oleg Bartunov|{{messageLink|Pine.LNX.4.64.0811191828050.7862@sn.sai.msu.ru|benefits of btree_gin}}}}<br />
<br />
{{patch|20081101000154.GO27872@fune|On-disk bitmap indexes|status=WIP|Gabriele Bartolini, Gianni Ciolli|reviewers=Greg Stark (more welcome!)}}<br />
{{review|49130E72.1000803@sigaev.ru|Teodor Sigaev|several bugs}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Performance ===<br />
<br />
{{patch|6EEA43D22289484890D119821101B1DF2C1683@exchange20.mercury.ad.ubc.ca|Improve Performance of Multi-Batch Hash Join for Skewed Data Sets|Ramon Lawrence/Bryce Cutt|reviewers=Joshua Tolley}}<br />
{{comment|Joshua Tolley|[http://archives.postgresql.org/pgsql-hackers/2008-11/msg00286.php] reports backend crash}}<br />
{{comment|tgl|updated patch {{messageLink|1924d1180811051606w19aaf30du589e8ea10ea5534d@mail.gmail.com|here}}}}<br />
{{comment|tgl|some concerns {{messageLink|22901.1227228246@sss.pgh.pa.us|here}}}}<br />
{{comment|Dave Page|Josh reports performance testing is ongoing 2008-11-26}}<br />
<br />
{{patch|87ljw5c0lx.fsf@oxford.xeocode.com|posix_fadvise|Gregory Stark|reviewers=Robert Haas|status=Waiting on author}}<br />
{{review|603c8f070811131912l7054a0bex33a50850f1a43656@mail.gmail.com|Robert Haas|looks pretty clean, but needs some cleanup, maybe should be 2 patches}}<br />
{{comment|Dave Page|{{messageLink|87myfxhxh1.fsf@oxford.xeocode.com|Latest patch (v20)}}}}<br />
{{comment|Robert Haas|author still needs to {{messageLink|603c8f070811181955j367bdd82m712465740e7d36ea@mail.gmail.com|rip out some more posix_fallocate stuff}} and maybe {{messageLink|603c8f070811182001r3870122ep3f4ff69c1c93ef30@mail.gmail.com|fine-tune the docs}}}}<br />
<br />
{{patch|a778a7260810280033n43f70d36x8c437eacf9a5461e@mail.gmail.com|Proposal of PITR performance improvement|Koichi Suzuki|reviewers=Simon Riggs}}<br />
{{comment|Robert Haas|{{messageLink|a778a7260811270404g49254640x8ed58b12b7c65d0b@mail.gmail.com|V2}} from patch author}}<br />
<br />
{{patch|36e682920811021349h7202bdecpd7a45c8a8038465e@mail.gmail.com|Hash Join-Filter Pruning using Bloom Filters|status=WIP|Jonah Harris|reviewers=Unicron}}<br />
{{comment|Uincron|can be built successfully, and find no questions after a view of code}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Improving admin experience ===<br />
<br />
{{patch|20081029183248.GE4331@alvh.no-ip.org|Block-level CRC checks|Alvaro Herrera|status=WIP}}<br />
{{comment|alvherre|{{messageLink|20081107191140.GE5507@alvh.no-ip.org|updated patch}} here}}<br />
<br />
{{patch|a301bfd90810310750pf108c69x36499546f406650f@mail.gmail.com|Auto Partitioning Patch|Nikhil Sontakke|status=WIP|reviewers=Jaime Casanova}}<br />
{{comment|jcasanov|some comments {{messageLink|3073cc9b0811052047o4ebe24b4vd0ab24fd3095d342@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|a few more thoughts {{messageLink|603c8f070811262009v459d0701w151c16533d4ab947@mail.gmail.com|here}}}}<br />
<br />
{{patch|1223379173.4747.145.camel@ebony.2ndQuadrant|Reducing some DDL Locks to ShareLock|status=Waiting on author|Simon Riggs|reviewers=Tom Lane}} <br />
{{comment|tgl|{{messageLink|1223404726.4747.249.camel@ebony.2ndQuadrant|v6 patch here}}}}<br />
{{comment|sriggs|agreed rework to implement pg_domain constraint, but the main patch still needs review}}<br />
{{comment|tgl|I think we'd decided to pass on the pg_constraint restructuring, at least for now}}<br />
{{comment|tgl|partially applied, what's left is {{messageLink|17459.1226279911@sss.pgh.pa.us|here}}}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Connection management ===<br />
<br />
{{patch|20080801203157.GL4321@alvh.no-ip.org|Client SSL key/certificate/etc file name specification|Alvaro Herrera|reviewers=Magnus Hagander, Alex Hunsaker}}<br />
{{comment|Magnus|Picked up from having been dropped from a previous commit fest, this is the latest updated version}}<br />
{{comment|Magnus|{{messageLink|34d269d40811202107q489e2be0h771762398dd9fcdb@mail.gmail.com|Updated patch}} 2008-11-20}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Contrib modules ===<br />
<br />
{{patch|20081011172450.3402.52131E4D@oss.ntt.co.jp|contrib/pg_stat_statements|Takahiro Itagaki|reviewers=Alex Hunsaker}}<br />
{{comment|Itagaki|updated version {{messageLink|20081202170106.A0EC.52131E4D@oss.ntt.co.jp|here}} (2008-12-02).}}<br />
<br />
{{patch|e4ccc24e0810222010p12bae2f4xa3a11cb2bc51bd89@mail.gmail.com|pg_standby support for compressed segments|Charles Duffy|reviewers=Simon Riggs}}<br />
{{comment|Simon Riggs|Deferring review for a few weeks until we get a better picture of streaming replication requirements for 8.4}}<br />
<br />
{{patch|Pine.GSO.4.64.0811012101220.17619@westnet.com|Simple postgresql.conf wizard|Greg Smith|reviewers=Josh Berkus,Nathan Boley}}<br />
{{comment|Greg Smith|{{messageLink|Pine.GSO.4.64.0811090226060.26272@westnet.com|Updated V2}}}}<br />
{{comment|Greg Smith|{{messageLink|Pine.GSO.4.64.0811291403040.12885@westnet.com|Updated V3}}}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Clients ===<br />
<br />
{{patch|48F04B7C.3080303@benedekl.tvnetwork.hu|pg_dump roles support|Benedek Laszlo|reviewers=Ibrar Ahmed|Status=Waiting for Author}}<br />
{{comment|alvherre|there's an {{messageLink|4912FA4E.1090000@benedekl.tvnetwork.hu|updated patch}}, and some extra {{messageLink|20081107202000.GG5507@alvh.no-ip.org|comments}}}}<br />
<br />
{{patch|490878AC.1@dunslane.net|parallel restore|status=WIP|Andrew Dunstan|reviewers=Kenneth Marshall}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Miscellaneous ===<br />
<br />
{{patch|03c301c91737$be5a2a30$0e01a8c0@IBMC9A0F63B40D|Solve a problem of LC_TIME of windows|Hiroshi Saito}}<br />
{{comment|mha|Even newer version {{messageLink|492AA5CD.8050001@hagander.net|here}}}}<br />
{{comment|itagaki|a new version of the patch {{messageLink|20081125173024.7B45.52131E4D@oss.ntt.co.jp|here}}}}<br />
<br />
{{patch|48F53EC0.3020004@timbira.com|autovacuum and reloption|Euler Taveira de Oliveira|reviewers=Alvaro Herrera}}<br />
{{comment|alvherre|{{messageLink|4938A37E.9080301@timbira.com|new version}}, various fixes}}<br />
<br />
{{patch|49097338.2070700@gmail.com|SQL/MED compatible connection manager|Martin Pihlak|reviewers=Peter Eisentraut}}<br />
{{comment|Martin Pihlak|Updated patch {{messageLink|49403EBE.8070801@gmail.com|here}}}}<br />
<br />
{{patch|20081029164000.GL27466@fetter.org|pre-MED|David Fetter|reviewers=Alex Hunsaker|status=Waiting on author}}<br />
{{comment|David Fetter|Updated patch {{messageLink|20081031144852.GF15545@fetter.org|here}}}}<br />
{{review|34d269d40811031902p1d73d177w9f2e721ae169e8be@mail.gmail.com|alexhun|few questions and tgl had some constructive {{messageLink|24867.1225819435@sss.pgh.pa.us|comments}}}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Committed patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|20080803.114711.73374027.t-ishii@sraoss.co.jp|Common Table Expressions|Yoshiyuki Asaba|status=Committed 2008-10-04|reviewers=Jeff Davis}}<br />
{{comment|David Fetter|README is {{messageLink|20080818.163852.105172778.t-ishii@sraoss.co.jp|here.}}}}<br />
{{comment|David Fetter|Git repository is [http://git.postgresql.org/git/~davidfetter/cte/.git here.]}}<br />
{{comment|David Fetter|[[CTEReadme]]}}<br />
{{comment|David Fetter|[[CTESQLStandard| Fair Use from the draft SQL:2008 standard (WIP)]]}}<br />
{{review|13449.1221589943@sss.pgh.pa.us|tgl|needs a good bit of work yet}}<br />
<br />
{{patch|Pine.GSO.4.64.0809152349440.19910@westnet.com|Add default_val to pg_settings|status=Committed 2008-10-06|Greg Smith|reviewers=Simon Riggs,Magnus Hagander}}<br />
<br />
{{patch|20081016102603.897D.52131E4D@oss.ntt.co.jp|Noisy _dosmaperror|status=Committed 2008-10-16|Takahiro Itagaki|reviewers=Tom Lane}}<br />
<br />
{{patch|b4e5ce320810151918g2acf69ebh9f80f4f2e1c203a0@mail.gmail.com|Memory leak on hashed agg rescan|status=Committed 2008-10-16|Neil Conway|reviewers=Tom Lane}}<br />
{{review|10455.1224160007@sss.pgh.pa.us|Tom Lane|move some logic to separate function}}<br />
<br />
{{patch|1223383838.4747.154.camel@ebony.2ndQuadrant|Atomic subtransaction commit|status=Committed 2008-10-20|Simon Riggs|reviewers=Alvaro Herrera}} <br />
<br />
{{patch|3327.1224535092@sss.pgh.pa.us|add placeholder variables to planner|status=Committed 2008-10-22|Tom Lane}}<br />
<br />
{{patch|48E271C5.7010907@hagander.net|pg_hba options parsing|status=Committed 2008-10-23|Magnus Hagander|reviewers=Bruce Momjian}}<br />
{{comment|Robert Haas|{{messageLink|48F0DE8B.8030004@hagander.net|updated patch}}}}<br />
<br />
{{patch|48FC3994.8040809@hagander.net|libpq ssl -> clear fallback looses error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905D22D.9040001@hagander.net|better hba parsing error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905A1DE.5030102@hagander.net|remove crypt authentication|status=Committed 2008-10-28|Magnus Hagander}}<br />
<br />
{{patch|4905F515.3020208@gmx.net|Unicode escapes in literals|status=Committed 2008-10-29|Peter Eisentraut}}<br />
<br />
{{patch|490A138E.80100@enterprisedb.com|User defined I/O conversion casts|status=Committed 2008-10-31|Heikki Linnakangas}}<br />
<br />
{{patch|49085327.5010608@enterprisedb.com|Updating FSM on recovery|status=Committed 2008-10-31|Heikki Linnakangas}}<br />
<br />
{{patch|Pine.BSO.4.64.0810271955030.28764@leary.csoft.net|use new heap_(form/deform/modify)_tuple API|Kris Jurka|reviewers=Zdenek Kotala|status=Committed 2008-11-01}}<br />
{{comment|Zdenek Kotala| It seems OK. Needs apply also {{messageLink|Pine.BSO.4.64.0810281721500.6833@leary.csoft.net|pfree patch.}}}}<br />
<br />
{{patch|Pine.BSO.4.64.0810281622240.9851@leary.csoft.net|don't use MAKE_PTR/OFFSET for shmem pointers|Kris Jurka|reviewers=Tom Lane|status=Committed 2008-11-02}}<br />
<br />
{{patch|48C181D4.8030807@gmail.com|reducing statistics write overhead|Martin Pihlak|reviewers=Tom Lane|status=Committed 2008-11-02}}<br />
{{comment|Martin Pihlak|Latest patch {{messageLink|48C594D8.6050504@gmail.com|here}}}}<br />
<br />
{{patch|37ed240d0809030015u73b65b66v70fd76741317c6f5@mail.gmail.com|pg_typeof()|Brendan Jurd|reviewers=Kurt Harriman|status=Committed 2008-11-03}}<br />
{{comment|Kurt Harriman|{{messageLink|http://archives.postgresql.org/pgsql-hackers/2008-11/msg00080.php|Updated patch}} is ready to commit if there is no objection}}<br />
<br />
{{patch|Pine.BSO.4.64.0810081931240.11647@leary.csoft.net|Fixes for psql describeOneTableDetails|Kris Jurka|reviewers=Tom Lane|status=Committed 2008-11-03}}<br />
<br />
{{patch|48E22CF5.4050503@sun.com|PageGetTempPage cleanup |Zdenek Kotala|reviewers=Tom Lane|status=Committed 2008-11-03}}<br />
{{comment|Zdenek Kotala|Original discussion {{messageLink|4938.1217862947@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|603c8f070810092009s1312d30bxc854cdfb5d9fed7e@mail.gmail.com|Allow the UUID type to accept non-standard formats|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-03}}<br />
<br />
{{patch|603c8f070810101937n776c1e7cvd6a12345b0bbda28@mail.gmail.com|array_ndims|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-04}}<br />
<br />
{{patch|603c8f070810282045g7fa6bdf9p53f03114d49643d7@mail.gmail.com|bulk inserts - keep most recent page pinned|Robert Haas|reviewers=Tom Lane|status=Committed 2008-11-06}}<br />
{{comment|Robert Haas|based on work by Simon Riggs: [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01080.php original idea],[http://archives.postgresql.org/pgsql-patches/2008-02/msg00140.php original patch], [http://archives.postgresql.org/pgsql-patches/2008-02/msg00154.php Tom Lane's comments]}}<br />
{{comment|Robert Haas|Tom's comments on my [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01276.php design proposal] are {{messageLink|17996.1225049097@sss.pgh.pa.us|here}}}}<br />
{{comment|Robert Haas|patch {{messageLink|603c8f070811011023n202aea33w4da13b7d14f74134@mail.gmail.com|v2}}, adjusting for Heikki's changes to the ReadBuffer interface}}<br />
<br />
{{patch|490394B7.6090503@lelarge.info|ALTER DATABASE SET TABLESPACE Statement|Guillaume Lelarge|reviewers=Bernd Helmle|status=Committed 2008-11-07}}<br />
{{comment|Bernd Helmle|Syntax discussion and updated version {{messageLink|C0F6602797884925406AB88F@imhotep.credativ.de|here}}}}<br />
{{comment|Guillaume Lelarge|Updated version with SET syntax {{messageLink|4910E46E.4010000@lelarge.info|here}}}}<br />
{{comment|Bernd Helmle|Updated version from Guillaume {{messageLink|4912C88A.2070808@lelarge.info|here}}}}<br />
{{comment|Guillaume Lelarge|Updated version {{messageLink|49140181.3000903@lelarge.info|here}}}}<br />
<br />
{{patch|0BD2E4E9-AF5A-4B4F-B546-027424EE8FAD@kineticode.com|Tests citext casts|David Wheeler|reviewers=<br />
Kenneth Marshall|status=Committed 2008-11-07}}<br />
<br />
{{patch|48D15471.6080305@cheapcomplexdevices.com|SQL Standard Interval output and IntervalStyle GUC|Ron Mayer|status=Committed 2008-11-08|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|Early updates {{messageLink|48D52E48.406@cheapcomplexdevices.com|here}}, {{messageLink|48E49BDC.4090402@cheapcomplexdevices.com|here}}, and [http://0ape.com/postgres_interval_patches/ here]. Mostly related to GUC changes.}}<br />
{{review|37ed240d0811032122u56db1959h91f53bbb9733c90d@mail.gmail.com|BJ|Bug in output, stylistic suggestions}}<br />
{{comment|the mailing list|Feedback from {{messageLink|19477.1225814409@sss.pgh.pa.us|Tom L}} and {{messageLink|49101C94.EE98.0025.0@wicourts.gov|Kevin G}} about mixed-sign intervals}}<br />
{{comment|Ron Mayer|Updated patch {{messageLink|4910B1DB.4000000.cheapcomplexdevices@com|here}} to fix -12:01:-30 bug and style suggestions from the review and to attempt to address feedback about mixed-sign intervals with doc updates.}}<br />
{{review|37ed240d0811042102q78df5b86t2ff2092a75d371d7@mail.gmail.com|BJ|One last typo in docs but otherwise all good; review complete}}<br />
{{review|28915.1226109473@sss.pgh.pa.us|Tom L|Tom pointed out issues with pg_dump and restore into databases with a different interval style}}<br />
{{comment|Ron Mayer|{{messageLink|4915AC0A.9070608@cheapcomplexdevices.com|Speculating}} if an analogy with standard_conforming_strings applies to how we can handle dump/restore.}}<br />
<br />
{{patch|48E4A30C.3000503@cheapcomplexdevices.com|status=Committed 2008-11-10|ISO 8601 interval literal input and output|Ron Mayer|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|The initial (2003) version of this patch along with a thread which explains the feature a bit more can be found [http://archives.postgresql.org/pgsql-patches/2003-09/msg00103.php here].}}<br />
{{comment|Robert Haas|{{messageLink|490BA342.7010300@cheapcomplexdevices.com|latest version}}}}<br />
{{review|37ed240d0811050750v11726fd1of441646f87b583da@mail.gmail.com|BJ|Code style and documentation suggestions}}<br />
{{comment|Ron Mayer|Update here [http://0ape.com/postgres_interval_patches/ here] that fixes style & docs; as well as a bug where the ISO8601 spec wasn't quite followed (an optional field was treated as required by previous patches).}}<br />
{{review|37ed240d0811062058n752c3880kb04feb85e355b524@mail.gmail.com|BJ|Query behaviour of 'P0001', final doc cleanup suggestions}}<br />
{{comment|Ron Mayer|Update here [http://0ape.com/postgres_interval_patches/ here] that fixes 'P0001' and updated docs.}}<br />
<br />
{{patch|48CEDE68.7090501@cheapcomplexdevices.com|Interval rounding consistency|Ron Mayer|status=Committed 2008-11-11|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|Patch 3 [http://0ape.com/postgres_interval_patches/ here] refactors the interval code to remove much of the copy&paste in DecodeInterval and EncodeInterval with the side effect of making interval rounding more consistent between styles. This patch applies on top of the IntervalStyle patch and the ISO 8601 Interval patch.}}<br />
{{review|37ed240d0811101214l4d4427d8jcdf64486fd254db9@mail.gmail.com|BJ|Code style cleanups, a couple queries}}<br />
<br />
{{patch|20952F54-6730-49D8-99A3-1834697790B5@decibel.org|array_length|Jim C. Nasby|reviewers=Peter Eisentraut|status=Committed 2008-11-12}}<br />
{{comment|Robert Haas|I have {{messageLink|603c8f070811062006q4f20b2bq179d4d2ffec65690@mail.gmail.com|reimplemented this in C}}}}<br />
<br />
{{patch|48FC7E84.3080702@hagander.net|SSL cleanups/hostname verification|Magnus Hagander|reviewers=Alex Hunsaker|status=Committed 2008-11-13}}<br />
{{comment|Magnus|{{messageLink|491985B1.3090300@hagander.net|Updated patch}}}}<br />
{{review|34d269d40811120805i16400cfck972b2aebac6eba44@mail.gmail.com|alexhun|looks good}}<br />
<br />
{{patch|603c8f070810151933p445978b3td481a5422a2aebf4@mail.gmail.com|array_agg/array_accum|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-13}}<br />
{{comment|Robert Haas|{{messageLink|1225045937.4434.21.camel@localhost.localdomain|another version}} and {{messageLink|1225682527.1375.150.camel@jdavis|another one}} from Jeff Davis}}<br />
<br />
{{patch|20081009165157.9BE4.52131E4D@oss.ntt.co.jp|contrib/auto_explain|status=Committed 2008-11-18|Takahiro Itagaki|reviewers=Jeff Davis}}<br />
{{comment|Jeff|{{messageLink|1226426084.3002.76.camel@jdavis|minor documentation edits by reviewer}}}}<br />
{{comment|Itagaki|{{messageLink|20081118114842.ED3F.52131E4D@oss.ntt.co.jp|latest patch versions}}}}<br />
<br />
{{patch|49009D67.4040202@hagander.net|clientcert option for pg_hba|Magnus Hagander|reviewers=Unicron, Alex Hunsaker|status=Committed 2008-11-20}}<br />
{{review|34d269d40811151420p24f80a5i206febbb2ecd0831@mail.gmail.com|alexhun|Quick review, new patch looks good}}<br />
<br />
{{patch|491C1E2D.8060905@hagander.net|client certificate authentication|Magnus Hagander|reviewers=Alex Hunsaker|status=Committed 2008-11-20}}<br />
{{comment|Magnus|Dependant on the "clientcert option for pg_hba" patch}}<br />
{{review|34d269d40811151600jb0dce03mf5d03f4829bbf59c@mail.gmail.comm|alexhun|Looks good}}<br />
<br />
{{patch|4909726F.8000800@gmx.net|TABLE command|Peter Eisentraut|status=Committed 2008-11-20|reviewers=Unicron, Robert Haas}}<br />
{{comment|Unicron|Patch {{messageLink|850603.14426.qm@web62408.mail.re1.yahoo.com|works per specification}}}}<br />
{{review|603c8f070811081050k79926d12x6547ae72abaa41af@mail.gmail.com|Robert Haas|wrong non-terminal, needs doc and psql updates}}<br />
<br />
{{patch|c2ee6dbd0810100553gd328275ue2eb6e14bee70a8@mail.gmail.com|adding VERBOSE option to CLUSTER|Jim Cox|status=Committed 2008-11-24|reviewers=Peter Eisentraut}}<br />
<br />
{{patch|49076F39.1080502@hagander.net|regexp support in usermaps|Magnus Hagander|reviewers=Gianni Ciolli|status=Committed 2008-11-28}}<br />
{{comment|Magnus|{{messageLink|49198FA5.6020206@hagander.net|Updated patch}}}}<br />
{{comment|Gianni Ciolli|The second version looks like ready to me.}}<br />
<br />
{{patch|1223472186.4747.301.camel@ebony.2ndQuadrant|pg_stop_backup wait bug fix|Simon Riggs|reviewers=Ibrar Ahmed, Heikki Linnakangas|status=Committed 2008-12-03}}<br />
{{comment|Robert Haas|sriggs extracted this from recovery infrastructure patch per {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's suggestion}}}}<br />
{{comment|Robert Haas|heikki has {{messageLink|493596CE.6040408@enterprisedb.com|an updated version}}}}<br />
<br />
{{patch|4905AE17.7090305@enterprisedb.com|Visibility map, partial vacuums|status=Waiting on author|Heikki Linnakangas|reviewers=Tom Lane|status=Committed 2008-12-03}}<br />
{{comment|tgl|updated patch {{messageLink|4925664C.3090605@enterprisedb.com|here}}}}<br />
{{comment|tgl|Nearly committable, some nits {{messageLink|26361.1227467112@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|200810271936.m9RJaGW09544@momjian.us|libpq callback unregistration|Bruce Momjian|reviewers=Magnus Hagander|status=Committed 2008-12-03}}<br />
{{comment|Magnus|Needs more work, comments {{messageLink|490EEF2D.2050703@hagander.net|here}}}}<br />
{{comment|alvherre|Bruce posted a {{messageLink|200811050502.mA552TJ20677@momjian.us|new version}}, but it still {{messageLink|20081107201029.GF5507@alvh.no-ip.org|needs some work}}}}<br />
{{comment|Magnus|Updated {{messageLink|200811210002.mAL02gQ26376@momjian.us|patch}}}}<br />
<br />
{{patch|162867790810260428p56d16352qa1ec5c4c5330f25c@mail.gmail.com|default values for function's parameters|Pavel Stehule|reviewers=Peter Eisentraut|status=Committed 2008-12-04}}<br />
{{comment|Pavel Stehule| fix known bugs, currently only doc should be finished}}<br />
{{comment|Peter Eisentraut|data type for catalog entries needs change}}<br />
{{comment|Robert Haas|Pavel just posted {{messageLink|162867790811261414w4a22e9edj4445d8da47794377@mail.gmail.com|a new version}} 2008-11-26}}<br />
<br />
{{patch|603c8f070808070503jd7be083kcce3e16345affb08@mail.gmail.com|add columns via CREATE OR REPLACE VIEW|Robert Haas|reviewers=Bernd Helmle|status=Committed 2008-12-06}}<br />
{{comment|Robert Haas|some further justification of the proposed design {{messageLink|603c8f070808070956t1ab98dcdr933575eb096e4c28@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|questions about how to move forward {{messageLink|603c8f070810031839y7ce9a852o86effbab9fd6dd9b@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|a {{messageLink|482096EC.3000805@dunslane.net|similar feature request}} from Andrew Dunstan}}<br />
{{comment|Dave Page|Bernd reports he has found some issues and expects to report to the list/Robert today 2008-11-27}}<br />
{{comment|Bernd Helmle|Found a problem when using domains with constraints {{messageLink|EC7E967B3307C67C3DD714D1@teje|here}}}}<br />
{{comment|Robert Haas|new version {{messageLink|603c8f070812011748p541f8593k57737d04554c15d5@mail.gmail.com|here}} 2008-12-01}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Returned with Feedback ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|1225010283.21241.33.camel@localhost.localdomain|new correlation metric|Jeff Davis|reviewers=Brendan Jurd|status=Pending rework}}<br />
<br />
{{patch|490B7C1B.8050408@sun.com|In-place online upgrade|status=Removed from queue per author|Zdenek Kotala|reviewers=Robert Haas}}<br />
{{comment|Zdenek Kotala|This patch requires "htup and bufpage API clean up" and "HeapTuple version extension" patches. Git repository is [http://git.postgresql.org here] }}<br />
{{review|603c8f070811022022x582a9cbdp60798a6b87910edf@mail.gmail.com|Robert Haas|preliminary comments, still need a clean diff}}<br />
<br />
{{patch|48F1FC7E.1060406@sun.com|Extending pg_class info + more flexible TOAST chunk size|Zdenek Kotala|reviewers=Robert Haas|status=Removed from queue per author}}<br />
{{comment|tgl|seems it'd be better to make TOAST chunks work like {{messageLink|490AB654.6040409@enterprisedb.com|this}}}}<br />
{{comment|tgl|Alvaro has a {{messageLink|20081117211021.GN4291@alvh.no-ip.org|draft patch}} for that}}<br />
<br />
{{patch|4909B326.507@enterprisedb.com|Optimizing COPY with memchr()|Heikki Linnakangas|status=WIP|reviewers=Robert Haas}}<br />
{{comment|tgl|does this really need any more review at this point?}}<br />
{{comment|Robert Haas|asked author for {{messageLink|603c8f070811081745v410d2ff5o4bd107d7fbb440f3@mail.gmail.com|a status update}}}}<br />
{{comment|Robert Haas|will {{messageLink|491A1266.9090305@enterprisedb.com|not be ready for 8.4}}}}<br />
<br />
{{patch|162867790810170316l4eeecb0bq321dd771f8f4e661@mail.gmail.com|grouping sets|status=WIP|Pavel Stehule|reviewers=Ibrar Ahmed}}<br />
{{comment|Pavel Stehule| doc and notes [[Grouping Sets]]}}<br />
{{comment|Pavel Stehule| actualised patch http://www.pgsql.cz/patches/gsets.diff.gz}}<br />
{{comment|tgl|Pavel says this is {{messageLink|162867790811240316y52227d88xe53527399b329e05@mail.gmail.com|not intended}} for 8.4}}<br />
{{comment|Ibrar| Review {{messageLink|162867790811240316y52227d88xe53527399b329e05@mail.gmail.com|complete}}}}<br />
<br />
{{patch|490B102A.10106@gmx.net|Distinct types|Peter Eisentraut|status=WIP}}<br />
{{comment|Bernd Helmle|Patch needs further work regarding {{messageLink|17750.1225571886@sss.pgh.pa.us|indexing}}}}<br />
{{comment|tgl|I don't think the {{messageLink|21942.1226084284@sss.pgh.pa.us|type-system behavior}} has been thought through properly}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Rejected Patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|f205bb120810280833x340324d3m19a4f8aa65d822b@mail.gmail.com|FAQ_Solaris 1.28 to spanish|Emanuel CALVO FRANCO|reviewers=Peter Eisentraut||status=Rejected}}<br />
{{comment|Peter Eisentraut|We are not ready to maintain translations of this type of material.}}<br />
<br />
{{patch|4909DFCE.1000702@sun.com|HeapTuple version extension + code cleanup|Zdenek Kotala|reviewers=Robert Haas|status=Rejected}}<br />
{{review|603c8f070811031822q7d3b33f7x8576b7028f498cc4@mail.gmail.com|Robert Haas|proposed API seems too costly and fragile}}<br />
{{comment|Robert Haas|I think we have consensus that {{messageLink|10341.1225762057@sss.pgh.pa.us|this is not the right approach}}}}<br />
<br />
{{patch|48EFA13C.2060407@frogthinker.org|Prepared transactions and temp tables|status=Rejected|Emmanuel Cecchet|reviewers=Heikki Linnakangas}}<br />
{{comment|tgl|new patch version {{messageLink|4914CD14.2060608@frogthinker.org|here}}}}<br />
{{comment|Robert Haas|{{messageLink|4934A4E0.8080208@frogthinker.org|new patch version}} from Emmanuel, who says he needs feedback from Heikki before proceeding further 2008-12-01}}<br />
{{comment|Heikki|I think we need to take a completely {{messageLink|492543D5.9050904@enterprisedb.com|different approach}}.}}<br />
<br />
{{patch|BLU110-W38CE0A22D467A8C3D9736CFF540@phx.gbl|Support PLUGINS lines in Makefiles, similar to MODULES|Asif Naeem|reviewers=Robert Haas|status=Rejected}}<br />
{{comment|Dave Page|This doesn't work with the edb-debugger plugin, which is the only such plugin around AFAIK. It needs to ignore comments on the PLUGINS line, and handle multiple targets (plugin_debugger, pldbgapi, targetinfo etc). Not sure if we want that complexity though.}}<br />
{{comment|Heikki|Unix-makefile version: {{messageLink|BLU110-W57823CEB7DC113354471EFF3B0@phx.gbl|here}}}}<br />
{{comment|Robert Haas|waiting for response to {{messageLink|603c8f070811280542q61ced9fdu5525ebb1234b2bf0@mail.gmail.com|email sent to author}} 2008-11-28}}<br />
{{comment|Robert Haas|no response from author 2008-12-05}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Round Robin Reviewers ==<br />
<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="width: 60%; border-collapse: collapse; border: 1px solid #ccc; font-size: 90%;"<br />
|- style="background: #eee;"<br />
! width="30%" | Name<br />
!Status<br />
!Reviewing<br />
!Completed<br />
|-<br />
|Brendan Jurd || Available || 0 || 4<br />
|-<br />
|Jaime Casanova || Available || 1 || 1<br />
|-<br />
|Stephen Frost || Available 11/15 || 0 || 0<br />
|-<br />
|Jeff Davis || Available || 2 || 1<br />
|-<br />
|Greg Stark || Unknown || 1 || 0<br />
|-<br />
|Abhijit Menon-Sen || Unknown || 0 || 0<br />
|-<br />
|Alex Hunsaker || Available || 1 || 1<br />
|-<br />
|Markus Wanner || Cherry-picking || 1 || 0<br />
|-<br />
|Ibrar Ahmed || Available || 1 || 0<br />
|-<br />
|D'Arcy Cain || Unknown || 0 || 0<br />
|-<br />
|Kenneth Marshall || Available || 1 || 1<br />
|-<br />
|Robert Haas || Available || 0 || 7<br />
|-<br />
|Matthew Wetmore || Out-of-contact || 0 || 0<br />
|-<br />
|Gianni Colli || Available || 1 || 0<br />
|-<br />
|"Unicron" || Available || 1 || 4<br />
|-<br />
|Pavan Deolasee || Available || 1 || 0<br />
|}</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-11&diff=3755CommitFest 2008-112008-12-06T17:36:12Z<p>Martin.pihlak: /* Miscellaneous */</p>
<hr />
<div>__TOC__<br />
<br />
This is the page for the CommitFest starting '''2008 November'''.<br />
<br />
Managers for this CommitFest are Josh Berkus (josh-at-agliodbs-com) and Dave Page (dpage-at-pgadmin-org).<br />
<br />
{{CommitFestCurrent}}<br />
<br />
== Pending patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
|-<br />
| colspan="4" |<br />
=== SE-PostgreSQL and related ===<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei|reviewers=Tom Lane, Simon Riggs, Bruce Momjian}}<br />
{{comment|KaiGai|[[SEPostgreSQL]] is a draft of comprehensive document}}<br />
{{comment|KaiGai|{{messageLink|4938F7FA.60805@ak.jp.nec.com|The latest patches to be reviewed (r1280), as of Dec. 5}}}}<br />
<br />
{{patch|20080901063855.GJ16005@tamriel.snowman.net|Column-level Permissions|Stephen Frost|status=Waiting on Author|reviewers=Markus Wanner,Alvaro Herrera}}<br />
{{comment|Stephen Frost|Updated patch {{messageLink|20080902221823.GL16005@tamriel.snowman.net|here}}}}<br />
{{review|48DB48AC.5010400@bluegap.ch|Markus Wanner|Awaiting updated patch.}}<br />
{{comment|Stephen Frost|Updated patch, again, {{messageLink|20081102034517.GR4452@tamriel.snowman.net|here}}}}<br />
{{comment|Stephen Frost|Updated patch, fixes case where unprivileged user can get row count, {{messageLink|20081102131332.GU4452@tamriel.snowman.net|here}}}}<br />
{{comment|alvherre|{{messageLink|20081114135033.GD3830@alvh.no-ip.org|Updated patch}}}}<br />
{{comment|Robert Haas|Stephen Frost agreed to make {{messageLink|20081125210308.GD4452@tamriel.snowman.net|some minor changes}} 2008-11-25}}<br />
|-<br />
| colspan="4" |<br />
<br />
=== Recovery, Replication, Hot Standby ===<br />
<br />
{{patch|1220213074.4371.173.camel@ebony.2ndQuadrant|Infrastructure changes for recovery|status=Waiting on author|Simon Riggs|reviewers=Tom Lane, Heikki Linnakangas}} <br />
{{comment|sriggs| important patch for other work}}<br />
{{comment|Robert Haas|{{messageLink|1223472898.4747.310.camel@ebony.2ndQuadrant|patch v9}} here, in response to {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's review}}}}<br />
{{comment|sriggs|some issues overlooked, fixed as part of Hot Standby patch only at present}}<br />
{{comment|sriggs|do we want this split out again as a separate patch for easier review?}}<br />
{{comment|Robert Haas|looks like the consensus is that this should be {{messageLink|2e78013d0811200149t29173598m5eb70f62c1dc02d4@mail.gmail.com|split back out as a separate patch}}}}<br />
{{comment|Dave Page|Heikki reports he is waiting on Simon for a split set of patches 2008-11-27}}<br />
<br />
{{patch|1225557138.3971.673.camel@ebony.2ndQuadrant|Hot Standby - queries during archive recovery|status=Pending Review|Simon Riggs|reviewers=Pavan Deolasee, Koichi Suzuki}}<br />
{{comment|sriggs| v5d now available, fixing all Mark's reported issues. Main parts are fully reviewable}}<br />
{{comment|sriggs| Wiki contains dynamically updated list of outstanding items [[Hot_Standby]] }}<br />
<br />
{{patch|1220174867.4371.107.camel@ebony.2ndQuadrant|rmgr hooks and contrib/rmgr_hook|status=Waiting on dependencies|Simon Riggs}} <br />
{{comment|sriggs| deferrable, if required}}<br />
{{comment|tgl|I think the plan is for this to wait till "infrastructure" patch goes in}}<br />
<br />
{{patch|3f0b79eb0810310436w360f0afdy76ff1499b177ce0d@mail.gmail.com|Synchronous log-shipping replication|Masao Fujii|reviewers=Heikki Linnakangas, Simon Riggs}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811040404r799d3170v5bb9f201000f1771@mail.gmail.com|signal handling patch v2}} here}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811050617o3237130awb4aec1d3a2daacab@mail.gmail.com|walsender process patch v1}} here}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811140215nd605e4u5ef56aee2ca6afea@mail.gmail.com|Synch Rep patch v2}} here}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811171908q2434a0bfrda0964987bb1a83a@mail.gmail.com|Synch Rep patch v3}} here}}<br />
{{comment|Dave Page|Heikki reports he is yet to review latest version. Is going to look at signal handling part, and commit first if OK 2008-11-27}}<br />
{{comment|fujii|Synch Rep patch v4 {{messageLink|3f0b79eb0811271845l4a8e4a20ga519aefc2a4d5162@mail.gmail.com|here}}}}<br />
{{comment|Dave Page|Simon reports his review is ongoing 2008-11-27}}<br />
{{comment|sriggs| {{messageLink|1228131740.20796.294.camel@hp_dx2400_1|First Thoughts on Code}}}}<br />
{{comment|fujii|I illustrated the architecture {{messageLink|3f0b79eb0812030437u4f9f56b3p6e78208b86a0dfb5@mail.gmail.com|here}}}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Upgrade-in-place and related issues === <br />
<br />
{{patch|49086E4C.9030602@sun.com|htup and bufpage API clean up|Zdenek Kotala|reviewers=Robert Haas|status=Waiting on author}}<br />
{{comment|Zdenek Kotala|New version is {{messageLink|490875FA.4020709@sun.com|here}}}}<br />
{{comment|Robert Haas|author {{messageLink|492D10DE.3020108@sun.com|plans to resubmit}} but it's {{messageLink|492E8AC1.6020808@sun.com|not his top priority}} 2008-11-26}}<br />
<br />
{{patch|49380BDD.1000903@sun.com|pg_upgrade script for 8.3->8.4|Zdenek Kotala|reviewers=Greg Smith}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== SQL language features ===<br />
<br />
{{patch|e08cc0400810270912u49a6ec83vc23984c01f368f76@mail.gmail.com|Window Functions|Hitoshi Harada|reviewers=Heikki Linnakangas, David Rowley, Tom Lane}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400810310721l22a6bb7kb6a300ce66443806@mail.gmail.com|here}}}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400811070746p43553f10s6bb09e98b7eafc3b@mail.gmail.com|here}}}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400811100548s1d31af73s888062c05c8512bd@mail.gmail.com|here}}, still some issues on {{messageLink|e08cc0400811100619w46a1b013x2051f6a8f2dad116@mail.gmail.com|ntile}} and {{messageLink|e08cc0400811100624o77744b15me1bc009b74d292c1@mail.gmail.com|nth_value}}}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400811120146r3c47b320g8aac5e22c05c8829@mail.gmail.com|here}}}}<br />
{{comment|Dave Page|David reports that he's waiting on an {{messageLink|492D1043.4080705@enterprisedb.com|updated patch}} from Heikki before continuing review 2008-11-26}}<br />
{{comment|Dave Page|Heikki reports he's not currently reviewing this, but has {{messageLink|492D1246.5070101@enterprisedb.com|refactored the code}} 2008-11-27}}<br />
{{comment|David Rowley|Patch is getting close. {{messageLink|839FB90FF49D4120B7107ED0D7B3E5B6@amd64|Comments}} 2008-12-05}}<br />
<br />
<br />
{{patch|603c8f070808070503jd7be083kcce3e16345affb08@mail.gmail.com|add columns via CREATE OR REPLACE VIEW|Robert Haas|reviewers=Bernd Helmle}}<br />
{{comment|Robert Haas|some further justification of the proposed design {{messageLink|603c8f070808070956t1ab98dcdr933575eb096e4c28@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|questions about how to move forward {{messageLink|603c8f070810031839y7ce9a852o86effbab9fd6dd9b@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|a {{messageLink|482096EC.3000805@dunslane.net|similar feature request}} from Andrew Dunstan}}<br />
{{comment|Dave Page|Bernd reports he has found some issues and expects to report to the list/Robert today 2008-11-27}}<br />
{{comment|Bernd Helmle|Found a problem when using domains with constraints {{messageLink|EC7E967B3307C67C3DD714D1@teje|here}}}}<br />
{{comment|Robert Haas|new version {{messageLink|603c8f070812011748p541f8593k57737d04554c15d5@mail.gmail.com|here}} 2008-12-01}}<br />
<br />
{{patch|2849137C693B65CC8E86411C@imhotep.credativ.de|Automatic view update rules|status=Waiting on author|Bernd Helmle|reviewers=Unicron,Robert Haas}}<br />
{{comment|Bernd Helmle|New version with RETURNING support {{messageLink|94CF655A8D0DC7D5B4B81D8B@imhotep.credativ.de|here}}}}<br />
{{comment|Wolf Wei|it can be built and executed successfully, automatic insert/update/delete on view based on single table can work}} <br />
{{review|603c8f070811112006q906b3a6o59a66228b7fc997@mail.gmail.com|Robert Haas|fails regression tests, and a few other comments 2008-11-11}}<br />
{{comment|Robert Haas|author {{messageLink|EB911BE7EC3A7A599A379DEF@teje|plans to resubmit}} 2008-11-26}}<br />
<br />
{{patch|1225543926.8122.14.camel@huvostro|Enable pl/python to return records based on multiple OUT params|Hannu Krosing|status=Waiting on author}}<br />
{{comment|Robert Haas|Hannu is {{messageLink|1225781532.7597.19.camel@huvostro|working on a new version}}}}<br />
{{comment|Robert Haas|oh, i guess Hannu actually {{messageLink|1227774392.8363.4.camel@huvostro|isn't working on a new version, but says the previous version is ready to go 2008-11-27}}}}<br />
{{comment|tgl|as I read the above-linked message, Hannu ''is'' still working on it}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Indexes ===<br />
<br />
{{patch|490B07BA.6030109@sigaev.ru|GIN fast insert|Teodor Sigaev, Oleg Bartunov|reviewers=Jeff Davis}}<br />
{{comment|Robert Haas|some {{messageLink|492F04D9.5070404@enterprisedb.com|complaints from Heikki}} 2008-11-27}}<br />
<br />
{{patch|490B3752.3010800@sigaev.ru|B-Tree emulation for GIN|status=WIP|Teodor Sigaev, Oleg Bartunov|reviewers=Jeff Davis}}<br />
{{comment|Teodor Sigaev|{{messageLink|491B1888.9020903@sigaev.ru|new version of btree_gin}}}}<br />
{{comment|Oleg Bartunov|{{messageLink|Pine.LNX.4.64.0811191828050.7862@sn.sai.msu.ru|benefits of btree_gin}}}}<br />
<br />
{{patch|20081101000154.GO27872@fune|On-disk bitmap indexes|status=WIP|Gabriele Bartolini, Gianni Ciolli|reviewers=Greg Stark (more welcome!)}}<br />
{{review|49130E72.1000803@sigaev.ru|Teodor Sigaev|several bugs}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Performance ===<br />
<br />
{{patch|6EEA43D22289484890D119821101B1DF2C1683@exchange20.mercury.ad.ubc.ca|Improve Performance of Multi-Batch Hash Join for Skewed Data Sets|Ramon Lawrence/Bryce Cutt|reviewers=Joshua Tolley}}<br />
{{comment|Joshua Tolley|[http://archives.postgresql.org/pgsql-hackers/2008-11/msg00286.php] reports backend crash}}<br />
{{comment|tgl|updated patch {{messageLink|1924d1180811051606w19aaf30du589e8ea10ea5534d@mail.gmail.com|here}}}}<br />
{{comment|tgl|some concerns {{messageLink|22901.1227228246@sss.pgh.pa.us|here}}}}<br />
{{comment|Dave Page|Josh reports performance testing is ongoing 2008-11-26}}<br />
<br />
{{patch|87ljw5c0lx.fsf@oxford.xeocode.com|posix_fadvise|Gregory Stark|reviewers=Robert Haas|status=Waiting on author}}<br />
{{review|603c8f070811131912l7054a0bex33a50850f1a43656@mail.gmail.com|Robert Haas|looks pretty clean, but needs some cleanup, maybe should be 2 patches}}<br />
{{comment|Dave Page|{{messageLink|87myfxhxh1.fsf@oxford.xeocode.com|Latest patch (v20)}}}}<br />
{{comment|Robert Haas|author still needs to {{messageLink|603c8f070811181955j367bdd82m712465740e7d36ea@mail.gmail.com|rip out some more posix_fallocate stuff}} and maybe {{messageLink|603c8f070811182001r3870122ep3f4ff69c1c93ef30@mail.gmail.com|fine-tune the docs}}}}<br />
<br />
{{patch|a778a7260810280033n43f70d36x8c437eacf9a5461e@mail.gmail.com|Proposal of PITR performance improvement|Koichi Suzuki|reviewers=Simon Riggs}}<br />
{{comment|Robert Haas|{{messageLink|a778a7260811270404g49254640x8ed58b12b7c65d0b@mail.gmail.com|V2}} from patch author}}<br />
<br />
{{patch|36e682920811021349h7202bdecpd7a45c8a8038465e@mail.gmail.com|Hash Join-Filter Pruning using Bloom Filters|status=WIP|Jonah Harris|reviewers=Unicron}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Improving admin experience ===<br />
<br />
{{patch|20081029183248.GE4331@alvh.no-ip.org|Block-level CRC checks|Alvaro Herrera|status=WIP}}<br />
{{comment|alvherre|{{messageLink|20081107191140.GE5507@alvh.no-ip.org|updated patch}} here}}<br />
<br />
{{patch|a301bfd90810310750pf108c69x36499546f406650f@mail.gmail.com|Auto Partitioning Patch|Nikhil Sontakke|status=WIP|reviewers=Jaime Casanova}}<br />
{{comment|jcasanov|some comments {{messageLink|3073cc9b0811052047o4ebe24b4vd0ab24fd3095d342@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|a few more thoughts {{messageLink|603c8f070811262009v459d0701w151c16533d4ab947@mail.gmail.com|here}}}}<br />
<br />
{{patch|1223379173.4747.145.camel@ebony.2ndQuadrant|Reducing some DDL Locks to ShareLock|status=Waiting on author|Simon Riggs|reviewers=Tom Lane}} <br />
{{comment|tgl|{{messageLink|1223404726.4747.249.camel@ebony.2ndQuadrant|v6 patch here}}}}<br />
{{comment|sriggs|agreed rework to implement pg_domain constraint, but the main patch still needs review}}<br />
{{comment|tgl|I think we'd decided to pass on the pg_constraint restructuring, at least for now}}<br />
{{comment|tgl|partially applied, what's left is {{messageLink|17459.1226279911@sss.pgh.pa.us|here}}}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Connection management ===<br />
<br />
{{patch|20080801203157.GL4321@alvh.no-ip.org|Client SSL key/certificate/etc file name specification|Alvaro Herrera|reviewers=Magnus Hagander, Alex Hunsaker}}<br />
{{comment|Magnus|Picked up from having been dropped from a previous commit fest, this is the latest updated version}}<br />
{{comment|Magnus|{{messageLink|34d269d40811202107q489e2be0h771762398dd9fcdb@mail.gmail.com|Updated patch}}}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Contrib modules ===<br />
<br />
{{patch|20081011172450.3402.52131E4D@oss.ntt.co.jp|contrib/pg_stat_statements|Takahiro Itagaki|reviewers=Alex Hunsaker}}<br />
{{comment|Itagaki|updated version {{messageLink|20081202170106.A0EC.52131E4D@oss.ntt.co.jp|here}} (2008-12-02).}}<br />
<br />
{{patch|e4ccc24e0810222010p12bae2f4xa3a11cb2bc51bd89@mail.gmail.com|pg_standby support for compressed segments|Charles Duffy|reviewers=Simon Riggs}}<br />
{{comment|Simon Riggs|Deferring review for a few weeks until we get a better picture of streaming replication requirements for 8.4}}<br />
<br />
{{patch|Pine.GSO.4.64.0811012101220.17619@westnet.com|Simple postgresql.conf wizard|Greg Smith|reviewers=Josh Berkus,Nathan Boley}}<br />
{{comment|Greg Smith|{{messageLink|Pine.GSO.4.64.0811090226060.26272@westnet.com|Updated V2}}}}<br />
{{comment|Greg Smith|{{messageLink|Pine.GSO.4.64.0811291403040.12885@westnet.com|Updated V3}}}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Clients ===<br />
<br />
{{patch|48F04B7C.3080303@benedekl.tvnetwork.hu|pg_dump roles support|Benedek Laszlo|reviewers=Ibrar Ahmed|Status=Waiting for Author}}<br />
{{comment|alvherre|there's an {{messageLink|4912FA4E.1090000@benedekl.tvnetwork.hu|updated patch}}, and some extra {{messageLink|20081107202000.GG5507@alvh.no-ip.org|comments}}}}<br />
<br />
{{patch|490878AC.1@dunslane.net|parallel restore|status=WIP|Andrew Dunstan|reviewers=Kenneth Marshall}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Miscellaneous ===<br />
<br />
{{patch|03c301c91737$be5a2a30$0e01a8c0@IBMC9A0F63B40D|Solve a problem of LC_TIME of windows|Hiroshi Saito}}<br />
{{comment|mha|Even newer version {{messageLink|492AA5CD.8050001@hagander.net|here}}}}<br />
{{comment|itagaki|a new version of the patch {{messageLink|20081125173024.7B45.52131E4D@oss.ntt.co.jp|here}}}}<br />
<br />
{{patch|48F53EC0.3020004@timbira.com|autovacuum and reloption|Euler Taveira de Oliveira|reviewers=Alvaro Herrera}}<br />
{{comment|alvherre|{{messageLink|4938A37E.9080301@timbira.com|new version}}, various fixes}}<br />
<br />
{{patch|49097338.2070700@gmail.com|SQL/MED compatible connection manager|Martin Pihlak|reviewers=Peter Eisentraut}}<br />
{{comment|Martin Pihlak|Updated patch {{messageLink|493AB7B9.2070505@gmail.com|here}}}}<br />
<br />
{{patch|20081029164000.GL27466@fetter.org|pre-MED|David Fetter|reviewers=Alex Hunsaker|status=Waiting on author}}<br />
{{comment|David Fetter|Updated patch {{messageLink|20081031144852.GF15545@fetter.org|here}}}}<br />
{{review|34d269d40811031902p1d73d177w9f2e721ae169e8be@mail.gmail.com|alexhun|few questions and tgl had some constructive {{messageLink|24867.1225819435@sss.pgh.pa.us|comments}}}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Committed patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|20080803.114711.73374027.t-ishii@sraoss.co.jp|Common Table Expressions|Yoshiyuki Asaba|status=Committed 2008-10-04|reviewers=Jeff Davis}}<br />
{{comment|David Fetter|README is {{messageLink|20080818.163852.105172778.t-ishii@sraoss.co.jp|here.}}}}<br />
{{comment|David Fetter|Git repository is [http://git.postgresql.org/git/~davidfetter/cte/.git here.]}}<br />
{{comment|David Fetter|[[CTEReadme]]}}<br />
{{comment|David Fetter|[[CTESQLStandard| Fair Use from the draft SQL:2008 standard (WIP)]]}}<br />
{{review|13449.1221589943@sss.pgh.pa.us|tgl|needs a good bit of work yet}}<br />
<br />
{{patch|Pine.GSO.4.64.0809152349440.19910@westnet.com|Add default_val to pg_settings|status=Committed 2008-10-06|Greg Smith|reviewers=Simon Riggs,Magnus Hagander}}<br />
<br />
{{patch|20081016102603.897D.52131E4D@oss.ntt.co.jp|Noisy _dosmaperror|status=Committed 2008-10-16|Takahiro Itagaki|reviewers=Tom Lane}}<br />
<br />
{{patch|b4e5ce320810151918g2acf69ebh9f80f4f2e1c203a0@mail.gmail.com|Memory leak on hashed agg rescan|status=Committed 2008-10-16|Neil Conway|reviewers=Tom Lane}}<br />
{{review|10455.1224160007@sss.pgh.pa.us|Tom Lane|move some logic to separate function}}<br />
<br />
{{patch|1223383838.4747.154.camel@ebony.2ndQuadrant|Atomic subtransaction commit|status=Committed 2008-10-20|Simon Riggs|reviewers=Alvaro Herrera}} <br />
<br />
{{patch|3327.1224535092@sss.pgh.pa.us|add placeholder variables to planner|status=Committed 2008-10-22|Tom Lane}}<br />
<br />
{{patch|48E271C5.7010907@hagander.net|pg_hba options parsing|status=Committed 2008-10-23|Magnus Hagander|reviewers=Bruce Momjian}}<br />
{{comment|Robert Haas|{{messageLink|48F0DE8B.8030004@hagander.net|updated patch}}}}<br />
<br />
{{patch|48FC3994.8040809@hagander.net|libpq ssl -> clear fallback looses error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905D22D.9040001@hagander.net|better hba parsing error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905A1DE.5030102@hagander.net|remove crypt authentication|status=Committed 2008-10-28|Magnus Hagander}}<br />
<br />
{{patch|4905F515.3020208@gmx.net|Unicode escapes in literals|status=Committed 2008-10-29|Peter Eisentraut}}<br />
<br />
{{patch|490A138E.80100@enterprisedb.com|User defined I/O conversion casts|status=Committed 2008-10-31|Heikki Linnakangas}}<br />
<br />
{{patch|49085327.5010608@enterprisedb.com|Updating FSM on recovery|status=Committed 2008-10-31|Heikki Linnakangas}}<br />
<br />
{{patch|Pine.BSO.4.64.0810271955030.28764@leary.csoft.net|use new heap_(form/deform/modify)_tuple API|Kris Jurka|reviewers=Zdenek Kotala|status=Committed 2008-11-01}}<br />
{{comment|Zdenek Kotala| It seems OK. Needs apply also {{messageLink|Pine.BSO.4.64.0810281721500.6833@leary.csoft.net|pfree patch.}}}}<br />
<br />
{{patch|Pine.BSO.4.64.0810281622240.9851@leary.csoft.net|don't use MAKE_PTR/OFFSET for shmem pointers|Kris Jurka|reviewers=Tom Lane|status=Committed 2008-11-02}}<br />
<br />
{{patch|48C181D4.8030807@gmail.com|reducing statistics write overhead|Martin Pihlak|reviewers=Tom Lane|status=Committed 2008-11-02}}<br />
{{comment|Martin Pihlak|Latest patch {{messageLink|48C594D8.6050504@gmail.com|here}}}}<br />
<br />
{{patch|37ed240d0809030015u73b65b66v70fd76741317c6f5@mail.gmail.com|pg_typeof()|Brendan Jurd|reviewers=Kurt Harriman|status=Committed 2008-11-03}}<br />
{{comment|Kurt Harriman|{{messageLink|http://archives.postgresql.org/pgsql-hackers/2008-11/msg00080.php|Updated patch}} is ready to commit if there is no objection}}<br />
<br />
{{patch|Pine.BSO.4.64.0810081931240.11647@leary.csoft.net|Fixes for psql describeOneTableDetails|Kris Jurka|reviewers=Tom Lane|status=Committed 2008-11-03}}<br />
<br />
{{patch|48E22CF5.4050503@sun.com|PageGetTempPage cleanup |Zdenek Kotala|reviewers=Tom Lane|status=Committed 2008-11-03}}<br />
{{comment|Zdenek Kotala|Original discussion {{messageLink|4938.1217862947@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|603c8f070810092009s1312d30bxc854cdfb5d9fed7e@mail.gmail.com|Allow the UUID type to accept non-standard formats|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-03}}<br />
<br />
{{patch|603c8f070810101937n776c1e7cvd6a12345b0bbda28@mail.gmail.com|array_ndims|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-04}}<br />
<br />
{{patch|603c8f070810282045g7fa6bdf9p53f03114d49643d7@mail.gmail.com|bulk inserts - keep most recent page pinned|Robert Haas|reviewers=Tom Lane|status=Committed 2008-11-06}}<br />
{{comment|Robert Haas|based on work by Simon Riggs: [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01080.php original idea],[http://archives.postgresql.org/pgsql-patches/2008-02/msg00140.php original patch], [http://archives.postgresql.org/pgsql-patches/2008-02/msg00154.php Tom Lane's comments]}}<br />
{{comment|Robert Haas|Tom's comments on my [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01276.php design proposal] are {{messageLink|17996.1225049097@sss.pgh.pa.us|here}}}}<br />
{{comment|Robert Haas|patch {{messageLink|603c8f070811011023n202aea33w4da13b7d14f74134@mail.gmail.com|v2}}, adjusting for Heikki's changes to the ReadBuffer interface}}<br />
<br />
{{patch|490394B7.6090503@lelarge.info|ALTER DATABASE SET TABLESPACE Statement|Guillaume Lelarge|reviewers=Bernd Helmle|status=Committed 2008-11-07}}<br />
{{comment|Bernd Helmle|Syntax discussion and updated version {{messageLink|C0F6602797884925406AB88F@imhotep.credativ.de|here}}}}<br />
{{comment|Guillaume Lelarge|Updated version with SET syntax {{messageLink|4910E46E.4010000@lelarge.info|here}}}}<br />
{{comment|Bernd Helmle|Updated version from Guillaume {{messageLink|4912C88A.2070808@lelarge.info|here}}}}<br />
{{comment|Guillaume Lelarge|Updated version {{messageLink|49140181.3000903@lelarge.info|here}}}}<br />
<br />
{{patch|0BD2E4E9-AF5A-4B4F-B546-027424EE8FAD@kineticode.com|Tests citext casts|David Wheeler|reviewers=<br />
Kenneth Marshall|status=Committed 2008-11-07}}<br />
<br />
{{patch|48D15471.6080305@cheapcomplexdevices.com|SQL Standard Interval output and IntervalStyle GUC|Ron Mayer|status=Committed 2008-11-08|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|Early updates {{messageLink|48D52E48.406@cheapcomplexdevices.com|here}}, {{messageLink|48E49BDC.4090402@cheapcomplexdevices.com|here}}, and [http://0ape.com/postgres_interval_patches/ here]. Mostly related to GUC changes.}}<br />
{{review|37ed240d0811032122u56db1959h91f53bbb9733c90d@mail.gmail.com|BJ|Bug in output, stylistic suggestions}}<br />
{{comment|the mailing list|Feedback from {{messageLink|19477.1225814409@sss.pgh.pa.us|Tom L}} and {{messageLink|49101C94.EE98.0025.0@wicourts.gov|Kevin G}} about mixed-sign intervals}}<br />
{{comment|Ron Mayer|Updated patch {{messageLink|4910B1DB.4000000.cheapcomplexdevices@com|here}} to fix -12:01:-30 bug and style suggestions from the review and to attempt to address feedback about mixed-sign intervals with doc updates.}}<br />
{{review|37ed240d0811042102q78df5b86t2ff2092a75d371d7@mail.gmail.com|BJ|One last typo in docs but otherwise all good; review complete}}<br />
{{review|28915.1226109473@sss.pgh.pa.us|Tom L|Tom pointed out issues with pg_dump and restore into databases with a different interval style}}<br />
{{comment|Ron Mayer|{{messageLink|4915AC0A.9070608@cheapcomplexdevices.com|Speculating}} if an analogy with standard_conforming_strings applies to how we can handle dump/restore.}}<br />
<br />
{{patch|48E4A30C.3000503@cheapcomplexdevices.com|status=Committed 2008-11-10|ISO 8601 interval literal input and output|Ron Mayer|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|The initial (2003) version of this patch along with a thread which explains the feature a bit more can be found [http://archives.postgresql.org/pgsql-patches/2003-09/msg00103.php here].}}<br />
{{comment|Robert Haas|{{messageLink|490BA342.7010300@cheapcomplexdevices.com|latest version}}}}<br />
{{review|37ed240d0811050750v11726fd1of441646f87b583da@mail.gmail.com|BJ|Code style and documentation suggestions}}<br />
{{comment|Ron Mayer|Update here [http://0ape.com/postgres_interval_patches/ here] that fixes style & docs; as well as a bug where the ISO8601 spec wasn't quite followed (an optional field was treated as required by previous patches).}}<br />
{{review|37ed240d0811062058n752c3880kb04feb85e355b524@mail.gmail.com|BJ|Query behaviour of 'P0001', final doc cleanup suggestions}}<br />
{{comment|Ron Mayer|Update here [http://0ape.com/postgres_interval_patches/ here] that fixes 'P0001' and updated docs.}}<br />
<br />
{{patch|48CEDE68.7090501@cheapcomplexdevices.com|Interval rounding consistency|Ron Mayer|status=Committed 2008-11-11|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|Patch 3 [http://0ape.com/postgres_interval_patches/ here] refactors the interval code to remove much of the copy&paste in DecodeInterval and EncodeInterval with the side effect of making interval rounding more consistent between styles. This patch applies on top of the IntervalStyle patch and the ISO 8601 Interval patch.}}<br />
{{review|37ed240d0811101214l4d4427d8jcdf64486fd254db9@mail.gmail.com|BJ|Code style cleanups, a couple queries}}<br />
<br />
{{patch|20952F54-6730-49D8-99A3-1834697790B5@decibel.org|array_length|Jim C. Nasby|reviewers=Peter Eisentraut|status=Committed 2008-11-12}}<br />
{{comment|Robert Haas|I have {{messageLink|603c8f070811062006q4f20b2bq179d4d2ffec65690@mail.gmail.com|reimplemented this in C}}}}<br />
<br />
{{patch|48FC7E84.3080702@hagander.net|SSL cleanups/hostname verification|Magnus Hagander|reviewers=Alex Hunsaker|status=Committed 2008-11-13}}<br />
{{comment|Magnus|{{messageLink|491985B1.3090300@hagander.net|Updated patch}}}}<br />
{{review|34d269d40811120805i16400cfck972b2aebac6eba44@mail.gmail.com|alexhun|looks good}}<br />
<br />
{{patch|603c8f070810151933p445978b3td481a5422a2aebf4@mail.gmail.com|array_agg/array_accum|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-13}}<br />
{{comment|Robert Haas|{{messageLink|1225045937.4434.21.camel@localhost.localdomain|another version}} and {{messageLink|1225682527.1375.150.camel@jdavis|another one}} from Jeff Davis}}<br />
<br />
{{patch|20081009165157.9BE4.52131E4D@oss.ntt.co.jp|contrib/auto_explain|status=Committed 2008-11-18|Takahiro Itagaki|reviewers=Jeff Davis}}<br />
{{comment|Jeff|{{messageLink|1226426084.3002.76.camel@jdavis|minor documentation edits by reviewer}}}}<br />
{{comment|Itagaki|{{messageLink|20081118114842.ED3F.52131E4D@oss.ntt.co.jp|latest patch versions}}}}<br />
<br />
{{patch|49009D67.4040202@hagander.net|clientcert option for pg_hba|Magnus Hagander|reviewers=Unicron, Alex Hunsaker|status=Committed 2008-11-20}}<br />
{{review|34d269d40811151420p24f80a5i206febbb2ecd0831@mail.gmail.com|alexhun|Quick review, new patch looks good}}<br />
<br />
{{patch|491C1E2D.8060905@hagander.net|client certificate authentication|Magnus Hagander|reviewers=Alex Hunsaker|status=Committed 2008-11-20}}<br />
{{comment|Magnus|Dependant on the "clientcert option for pg_hba" patch}}<br />
{{review|34d269d40811151600jb0dce03mf5d03f4829bbf59c@mail.gmail.comm|alexhun|Looks good}}<br />
<br />
{{patch|4909726F.8000800@gmx.net|TABLE command|Peter Eisentraut|status=Committed 2008-11-20|reviewers=Unicron, Robert Haas}}<br />
{{comment|Unicron|Patch {{messageLink|850603.14426.qm@web62408.mail.re1.yahoo.com|works per specification}}}}<br />
{{review|603c8f070811081050k79926d12x6547ae72abaa41af@mail.gmail.com|Robert Haas|wrong non-terminal, needs doc and psql updates}}<br />
<br />
{{patch|c2ee6dbd0810100553gd328275ue2eb6e14bee70a8@mail.gmail.com|adding VERBOSE option to CLUSTER|Jim Cox|status=Committed 2008-11-24|reviewers=Peter Eisentraut}}<br />
<br />
{{patch|49076F39.1080502@hagander.net|regexp support in usermaps|Magnus Hagander|reviewers=Gianni Ciolli|status=Committed 2008-11-28}}<br />
{{comment|Magnus|{{messageLink|49198FA5.6020206@hagander.net|Updated patch}}}}<br />
{{comment|Gianni Ciolli|The second version looks like ready to me.}}<br />
<br />
{{patch|1223472186.4747.301.camel@ebony.2ndQuadrant|pg_stop_backup wait bug fix|Simon Riggs|reviewers=Ibrar Ahmed, Heikki Linnakangas|status=Committed 2008-12-03}}<br />
{{comment|Robert Haas|sriggs extracted this from recovery infrastructure patch per {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's suggestion}}}}<br />
{{comment|Robert Haas|heikki has {{messageLink|493596CE.6040408@enterprisedb.com|an updated version}}}}<br />
<br />
{{patch|4905AE17.7090305@enterprisedb.com|Visibility map, partial vacuums|status=Waiting on author|Heikki Linnakangas|reviewers=Tom Lane|status=Committed 2008-12-03}}<br />
{{comment|tgl|updated patch {{messageLink|4925664C.3090605@enterprisedb.com|here}}}}<br />
{{comment|tgl|Nearly committable, some nits {{messageLink|26361.1227467112@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|200810271936.m9RJaGW09544@momjian.us|libpq callback unregistration|Bruce Momjian|reviewers=Magnus Hagander|status=Committed 2008-12-03}}<br />
{{comment|Magnus|Needs more work, comments {{messageLink|490EEF2D.2050703@hagander.net|here}}}}<br />
{{comment|alvherre|Bruce posted a {{messageLink|200811050502.mA552TJ20677@momjian.us|new version}}, but it still {{messageLink|20081107201029.GF5507@alvh.no-ip.org|needs some work}}}}<br />
{{comment|Magnus|Updated {{messageLink|200811210002.mAL02gQ26376@momjian.us|patch}}}}<br />
<br />
{{patch|162867790810260428p56d16352qa1ec5c4c5330f25c@mail.gmail.com|default values for function's parameters|Pavel Stehule|reviewers=Peter Eisentraut|status=Committed 2008-12-04}}<br />
{{comment|Pavel Stehule| fix known bugs, currently only doc should be finished}}<br />
{{comment|Peter Eisentraut|data type for catalog entries needs change}}<br />
{{comment|Robert Haas|Pavel just posted {{messageLink|162867790811261414w4a22e9edj4445d8da47794377@mail.gmail.com|a new version}} 2008-11-26}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Returned with Feedback ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|1225010283.21241.33.camel@localhost.localdomain|new correlation metric|Jeff Davis|reviewers=Brendan Jurd|status=Pending rework}}<br />
<br />
{{patch|490B7C1B.8050408@sun.com|In-place online upgrade|status=Removed from queue per author|Zdenek Kotala|reviewers=Robert Haas}}<br />
{{comment|Zdenek Kotala|This patch requires "htup and bufpage API clean up" and "HeapTuple version extension" patches. Git repository is [http://git.postgresql.org here] }}<br />
{{review|603c8f070811022022x582a9cbdp60798a6b87910edf@mail.gmail.com|Robert Haas|preliminary comments, still need a clean diff}}<br />
<br />
{{patch|48F1FC7E.1060406@sun.com|Extending pg_class info + more flexible TOAST chunk size|Zdenek Kotala|reviewers=Robert Haas|status=Removed from queue per author}}<br />
{{comment|tgl|seems it'd be better to make TOAST chunks work like {{messageLink|490AB654.6040409@enterprisedb.com|this}}}}<br />
{{comment|tgl|Alvaro has a {{messageLink|20081117211021.GN4291@alvh.no-ip.org|draft patch}} for that}}<br />
<br />
{{patch|4909B326.507@enterprisedb.com|Optimizing COPY with memchr()|Heikki Linnakangas|status=WIP|reviewers=Robert Haas}}<br />
{{comment|tgl|does this really need any more review at this point?}}<br />
{{comment|Robert Haas|asked author for {{messageLink|603c8f070811081745v410d2ff5o4bd107d7fbb440f3@mail.gmail.com|a status update}}}}<br />
{{comment|Robert Haas|will {{messageLink|491A1266.9090305@enterprisedb.com|not be ready for 8.4}}}}<br />
<br />
{{patch|162867790810170316l4eeecb0bq321dd771f8f4e661@mail.gmail.com|grouping sets|status=WIP|Pavel Stehule|reviewers=Ibrar Ahmed}}<br />
{{comment|Pavel Stehule| doc and notes [[Grouping Sets]]}}<br />
{{comment|Pavel Stehule| actualised patch http://www.pgsql.cz/patches/gsets.diff.gz}}<br />
{{comment|tgl|Pavel says this is {{messageLink|162867790811240316y52227d88xe53527399b329e05@mail.gmail.com|not intended}} for 8.4}}<br />
{{comment|Ibrar| Review {{messageLink|162867790811240316y52227d88xe53527399b329e05@mail.gmail.com|complete}}}}<br />
<br />
{{patch|490B102A.10106@gmx.net|Distinct types|Peter Eisentraut|status=WIP}}<br />
{{comment|Bernd Helmle|Patch needs further work regarding {{messageLink|17750.1225571886@sss.pgh.pa.us|indexing}}}}<br />
{{comment|tgl|I don't think the {{messageLink|21942.1226084284@sss.pgh.pa.us|type-system behavior}} has been thought through properly}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Rejected Patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|f205bb120810280833x340324d3m19a4f8aa65d822b@mail.gmail.com|FAQ_Solaris 1.28 to spanish|Emanuel CALVO FRANCO|reviewers=Peter Eisentraut||status=Rejected}}<br />
{{comment|Peter Eisentraut|We are not ready to maintain translations of this type of material.}}<br />
<br />
{{patch|4909DFCE.1000702@sun.com|HeapTuple version extension + code cleanup|Zdenek Kotala|reviewers=Robert Haas|status=Rejected}}<br />
{{review|603c8f070811031822q7d3b33f7x8576b7028f498cc4@mail.gmail.com|Robert Haas|proposed API seems too costly and fragile}}<br />
{{comment|Robert Haas|I think we have consensus that {{messageLink|10341.1225762057@sss.pgh.pa.us|this is not the right approach}}}}<br />
<br />
{{patch|48EFA13C.2060407@frogthinker.org|Prepared transactions and temp tables|status=Rejected|Emmanuel Cecchet|reviewers=Heikki Linnakangas}}<br />
{{comment|tgl|new patch version {{messageLink|4914CD14.2060608@frogthinker.org|here}}}}<br />
{{comment|Robert Haas|{{messageLink|4934A4E0.8080208@frogthinker.org|new patch version}} from Emmanuel, who says he needs feedback from Heikki before proceeding further 2008-12-01}}<br />
{{comment|Heikki|I think we need to take a completely {{messageLink|492543D5.9050904@enterprisedb.com|different approach}}.}}<br />
<br />
{{patch|BLU110-W38CE0A22D467A8C3D9736CFF540@phx.gbl|Support PLUGINS lines in Makefiles, similar to MODULES|Asif Naeem|reviewers=Robert Haas|status=Rejected}}<br />
{{comment|Dave Page|This doesn't work with the edb-debugger plugin, which is the only such plugin around AFAIK. It needs to ignore comments on the PLUGINS line, and handle multiple targets (plugin_debugger, pldbgapi, targetinfo etc). Not sure if we want that complexity though.}}<br />
{{comment|Heikki|Unix-makefile version: {{messageLink|BLU110-W57823CEB7DC113354471EFF3B0@phx.gbl|here}}}}<br />
{{comment|Robert Haas|waiting for response to {{messageLink|603c8f070811280542q61ced9fdu5525ebb1234b2bf0@mail.gmail.com|email sent to author}} 2008-11-28}}<br />
{{comment|Robert Haas|no response from author 2008-12-05}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Round Robin Reviewers ==<br />
<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="width: 60%; border-collapse: collapse; border: 1px solid #ccc; font-size: 90%;"<br />
|- style="background: #eee;"<br />
! width="30%" | Name<br />
!Status<br />
!Reviewing<br />
!Completed<br />
|-<br />
|Brendan Jurd || Available || 0 || 4<br />
|-<br />
|Jaime Casanova || Available || 1 || 1<br />
|-<br />
|Stephen Frost || Available 11/15 || 0 || 0<br />
|-<br />
|Jeff Davis || Available || 2 || 1<br />
|-<br />
|Greg Stark || Unknown || 1 || 0<br />
|-<br />
|Abhijit Menon-Sen || Unknown || 0 || 0<br />
|-<br />
|Alex Hunsaker || Available || 1 || 1<br />
|-<br />
|Markus Wanner || Cherry-picking || 1 || 0<br />
|-<br />
|Ibrar Ahmed || Available || 1 || 0<br />
|-<br />
|D'Arcy Cain || Unknown || 0 || 0<br />
|-<br />
|Kenneth Marshall || Available || 1 || 1<br />
|-<br />
|Robert Haas || Available || 0 || 7<br />
|-<br />
|Matthew Wetmore || Out-of-contact || 0 || 0<br />
|-<br />
|Gianni Colli || Available || 1 || 0<br />
|-<br />
|"Unicron" || Available || 1 || 3<br />
|-<br />
|Pavan Deolasee || Available || 1 || 0<br />
|}</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3754SqlMedConnectionManager2008-12-06T17:12:27Z<p>Martin.pihlak: /* dblink */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username. In this version the privilege are checked for the supplied user.<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPER pgsql<br />
OPTIONS (dbname 'foodb', host 'bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username 'bob', password 'salakala');<br />
<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (user 'bob', password 'salakala');<br />
<br />
select * from pg_get_remote_connection_info('foodb');<br />
<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
<br />
ERROR: permission denied for foreign server foodb<br />
<br />
GRANT USAGE ON SERVER foodb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER "default"<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
GRANT USAGE ON SERVER bazdb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('bazdb', 'bob');<br />
<br />
option | value <br />
-----------+-------<br />
tnsname | ORCL<br />
lusername | scott<br />
passw0rd | tiger<br />
(3 rows)<br />
<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER dbdtest;<br />
<br />
select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
option | value <br />
------------+----------------------------------<br />
datasource | DBI:Excel:file=dbdtest.xls<br />
attributes | {xl_vtbl => {TESTV => { ... } }}<br />
(2 rows)<br />
<br />
</pre><br />
<br />
===plproxy cluster===<br />
An example of how a plproxy cluster might be described. In reality 'default_fdw'<br />
would be replaced by the actual plproxy library.<br />
<pre><br />
<br />
CREATE FOREIGN DATA WRAPPER plproxy LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER userdb TYPE 'plproxy_cluster'<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (<br />
server1 'dbname=userdb_p0 host=127.0.0.1 port=6000',<br />
server2 'dbname=userdb_p1 host=127.0.0.1 port=6000',<br />
server3 'dbname=userdb_p2 host=127.0.0.1 port=6000',<br />
server4 'dbname=userdb_p3 host=127.0.0.1 port=6000',<br />
connection_lifetime=3600<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER userdb;<br />
<br />
select * from pg_get_remote_connection_info('userdb');<br />
option | value <br />
---------------------+-------------------------------------------<br />
server1 | dbname=userdb_p0 host=127.0.0.1 port=6000<br />
server2 | dbname=userdb_p1 host=127.0.0.1 port=6000<br />
server3 | dbname=userdb_p2 host=127.0.0.1 port=6000<br />
server4 | dbname=userdb_p3 host=127.0.0.1 port=6000<br />
connection_lifetime | 3600<br />
(5 rows)<br />
<br />
</pre><br />
<br />
===dblink===<br />
An example of how dblink can be used with foreign servers.<br />
<br />
<pre><br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'localhost', port '5432', dbname 'test');<br />
<br />
CREATE USER MAPPING FOR current_user SERVER foo OPTIONS (user 'test', password 'test');<br />
<br />
SELECT * FROM pg_get_remote_connection_info('foo');<br />
option_name | option_value <br />
-------------+--------------------------------------------------------------<br />
datasource | host=localhost port=5432 dbname=test user=test password=test<br />
(1 row)<br />
<br />
SELECT * FROM dblink_connect_s('c1', 'foo');<br />
dblink_connect_s<br />
-----------------<br />
OK<br />
(1 row)<br />
<br />
SELECT * FROM dblink('c1', 'select proname, prosrc from pg_proc') <br />
AS t1(proname name, prosrc text) WHERE proname LIKE 'byteal%';<br />
proname | prosrc <br />
-----------+-----------<br />
bytealt | bytealt<br />
byteale | byteale<br />
bytealike | bytealike<br />
(3 rows)<br />
<br />
Alternatively:<br />
<br />
SELECT * FROM dblink_s('foo', 'select proname, prosrc from pg_proc') <br />
AS t1(proname name, prosrc text) WHERE proname LIKE 'byteal%';<br />
proname | prosrc <br />
-----------+-----------<br />
bytealt | bytealt<br />
byteale | byteale<br />
bytealike | bytealike<br />
(3 rows)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3739SqlMedConnectionManager2008-12-05T14:17:26Z<p>Martin.pihlak: /* dblink */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username. In this version the privilege are checked for the supplied user.<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPER pgsql<br />
OPTIONS (dbname 'foodb', host 'bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username 'bob', password 'salakala');<br />
<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (user 'bob', password 'salakala');<br />
<br />
select * from pg_get_remote_connection_info('foodb');<br />
<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
<br />
ERROR: permission denied for foreign server foodb<br />
<br />
GRANT USAGE ON SERVER foodb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER "default"<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
GRANT USAGE ON SERVER bazdb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('bazdb', 'bob');<br />
<br />
option | value <br />
-----------+-------<br />
tnsname | ORCL<br />
lusername | scott<br />
passw0rd | tiger<br />
(3 rows)<br />
<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER dbdtest;<br />
<br />
select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
option | value <br />
------------+----------------------------------<br />
datasource | DBI:Excel:file=dbdtest.xls<br />
attributes | {xl_vtbl => {TESTV => { ... } }}<br />
(2 rows)<br />
<br />
</pre><br />
<br />
===plproxy cluster===<br />
An example of how a plproxy cluster might be described. In reality 'default_fdw'<br />
would be replaced by the actual plproxy library.<br />
<pre><br />
<br />
CREATE FOREIGN DATA WRAPPER plproxy LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER userdb TYPE 'plproxy_cluster'<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (<br />
server1 'dbname=userdb_p0 host=127.0.0.1 port=6000',<br />
server2 'dbname=userdb_p1 host=127.0.0.1 port=6000',<br />
server3 'dbname=userdb_p2 host=127.0.0.1 port=6000',<br />
server4 'dbname=userdb_p3 host=127.0.0.1 port=6000',<br />
connection_lifetime=3600<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER userdb;<br />
<br />
select * from pg_get_remote_connection_info('userdb');<br />
option | value <br />
---------------------+-------------------------------------------<br />
server1 | dbname=userdb_p0 host=127.0.0.1 port=6000<br />
server2 | dbname=userdb_p1 host=127.0.0.1 port=6000<br />
server3 | dbname=userdb_p2 host=127.0.0.1 port=6000<br />
server4 | dbname=userdb_p3 host=127.0.0.1 port=6000<br />
connection_lifetime | 3600<br />
(5 rows)<br />
<br />
</pre><br />
<br />
===dblink===<br />
An example of how dblink can be used with foreign servers.<br />
<br />
<pre><br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'localhost', port '5432', dbname 'test');<br />
<br />
CREATE USER MAPPING FOR current_user SERVER foo OPTIONS (user 'test', password 'test');<br />
<br />
SELECT * FROM pg_get_remote_connection_info('foo');<br />
option_name | option_value <br />
-------------+--------------------------------------------------------------<br />
datasource | host=localhost port=5432 dbname=test user=test password=test<br />
(1 row)<br />
<br />
select * from dblink_connect_server('c1', 'foo');<br />
dblink_connect_server <br />
-----------------------<br />
OK<br />
(1 row)<br />
<br />
SELECT * FROM dblink('c1', 'select proname, prosrc from pg_proc') <br />
AS t1(proname name, prosrc text) WHERE proname LIKE 'byteal%';<br />
proname | prosrc <br />
-----------+-----------<br />
bytealt | bytealt<br />
byteale | byteale<br />
bytealike | bytealike<br />
(3 rows)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3737SqlMedConnectionManager2008-12-05T11:52:08Z<p>Martin.pihlak: /* Examples */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username. In this version the privilege are checked for the supplied user.<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPER pgsql<br />
OPTIONS (dbname 'foodb', host 'bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username 'bob', password 'salakala');<br />
<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (user 'bob', password 'salakala');<br />
<br />
select * from pg_get_remote_connection_info('foodb');<br />
<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
<br />
ERROR: permission denied for foreign server foodb<br />
<br />
GRANT USAGE ON SERVER foodb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER "default"<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
GRANT USAGE ON SERVER bazdb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('bazdb', 'bob');<br />
<br />
option | value <br />
-----------+-------<br />
tnsname | ORCL<br />
lusername | scott<br />
passw0rd | tiger<br />
(3 rows)<br />
<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER dbdtest;<br />
<br />
select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
option | value <br />
------------+----------------------------------<br />
datasource | DBI:Excel:file=dbdtest.xls<br />
attributes | {xl_vtbl => {TESTV => { ... } }}<br />
(2 rows)<br />
<br />
</pre><br />
<br />
===plproxy cluster===<br />
An example of how a plproxy cluster might be described. In reality 'default_fdw'<br />
would be replaced by the actual plproxy library.<br />
<pre><br />
<br />
CREATE FOREIGN DATA WRAPPER plproxy LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER userdb TYPE 'plproxy_cluster'<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (<br />
server1 'dbname=userdb_p0 host=127.0.0.1 port=6000',<br />
server2 'dbname=userdb_p1 host=127.0.0.1 port=6000',<br />
server3 'dbname=userdb_p2 host=127.0.0.1 port=6000',<br />
server4 'dbname=userdb_p3 host=127.0.0.1 port=6000',<br />
connection_lifetime=3600<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER userdb;<br />
<br />
select * from pg_get_remote_connection_info('userdb');<br />
option | value <br />
---------------------+-------------------------------------------<br />
server1 | dbname=userdb_p0 host=127.0.0.1 port=6000<br />
server2 | dbname=userdb_p1 host=127.0.0.1 port=6000<br />
server3 | dbname=userdb_p2 host=127.0.0.1 port=6000<br />
server4 | dbname=userdb_p3 host=127.0.0.1 port=6000<br />
connection_lifetime | 3600<br />
(5 rows)<br />
<br />
</pre><br />
<br />
===dblink===<br />
An example of how dblink can be used with foreign servers.<br />
<br />
<pre><br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'localhost', port '5432', dbname 'test');<br />
<br />
CREATE USER MAPPING FOR current_user SERVER foo OPTIONS (user 'test', password 'test');<br />
<br />
SELECT * FROM pg_get_remote_connection_info('foo');<br />
option_name | option_value <br />
-------------+--------------------------------------------------------------<br />
datasource | host=localhost port=5432 dbname=test user=test password=test<br />
(1 row)<br />
<br />
select * from dblink_connect_server('foo');<br />
dblink_connect_server <br />
-----------------------<br />
OK<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3725SqlMedConnectionManager2008-12-04T08:22:05Z<p>Martin.pihlak: </p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username. In this version the privilege are checked for the supplied user.<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPER pgsql<br />
OPTIONS (dbname 'foodb', host 'bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username 'bob', password 'salakala');<br />
<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (user 'bob', password 'salakala');<br />
<br />
select * from pg_get_remote_connection_info('foodb');<br />
<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
<br />
ERROR: permission denied for foreign server foodb<br />
<br />
GRANT USAGE ON SERVER foodb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER "default"<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
GRANT USAGE ON SERVER bazdb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('bazdb', 'bob');<br />
<br />
option | value <br />
-----------+-------<br />
tnsname | ORCL<br />
lusername | scott<br />
passw0rd | tiger<br />
(3 rows)<br />
<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER dbdtest;<br />
<br />
select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
option | value <br />
------------+----------------------------------<br />
datasource | DBI:Excel:file=dbdtest.xls<br />
attributes | {xl_vtbl => {TESTV => { ... } }}<br />
(2 rows)<br />
<br />
</pre><br />
<br />
===plproxy cluster===<br />
An example of how a plproxy cluster might be described. In reality 'default_fdw'<br />
would be replaced by the actual plproxy library.<br />
<pre><br />
<br />
CREATE FOREIGN DATA WRAPPER plproxy LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER userdb TYPE 'plproxy_cluster'<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (<br />
server1 'dbname=userdb_p0 host=127.0.0.1 port=6000',<br />
server2 'dbname=userdb_p1 host=127.0.0.1 port=6000',<br />
server3 'dbname=userdb_p2 host=127.0.0.1 port=6000',<br />
server4 'dbname=userdb_p3 host=127.0.0.1 port=6000',<br />
connection_lifetime=3600<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER userdb;<br />
<br />
select * from pg_get_remote_connection_info('userdb');<br />
option | value <br />
---------------------+-------------------------------------------<br />
server1 | dbname=userdb_p0 host=127.0.0.1 port=6000<br />
server2 | dbname=userdb_p1 host=127.0.0.1 port=6000<br />
server3 | dbname=userdb_p2 host=127.0.0.1 port=6000<br />
server4 | dbname=userdb_p3 host=127.0.0.1 port=6000<br />
connection_lifetime | 3600<br />
(5 rows)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3598SqlMedConnectionManager2008-11-25T09:08:06Z<p>Martin.pihlak: /* plproxy cluster */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host='remotehost', dbname='remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username='bob', password='secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username. In this version the privilege are checked for the supplied user.<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (user='bob', password='salakala');<br />
<br />
select * from pg_get_remote_connection_info('foodb');<br />
<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
<br />
ERROR: permission denied for foreign server foodb<br />
<br />
GRANT USAGE ON SERVER foodb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER "default"<br />
OPTIONS (tnsname='ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername='scott', passw0rd='tiger');<br />
GRANT USAGE ON SERVER bazdb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('bazdb', 'bob');<br />
<br />
option | value <br />
-----------+-------<br />
tnsname | ORCL<br />
lusername | scott<br />
passw0rd | tiger<br />
(3 rows)<br />
<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource='DBI:Excel:file=dbdtest.xls',<br />
attributes='{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER dbdtest;<br />
<br />
select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
option | value <br />
------------+----------------------------------<br />
datasource | DBI:Excel:file=dbdtest.xls<br />
attributes | {xl_vtbl => {TESTV => { ... } }}<br />
(2 rows)<br />
<br />
</pre><br />
<br />
===plproxy cluster===<br />
An example of how a plproxy cluster might be described. In reality 'default_fdw'<br />
would be replaced by the actual plproxy library.<br />
<pre><br />
<br />
CREATE FOREIGN DATA WRAPPER plproxy LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER userdb TYPE 'plproxy_cluster'<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (<br />
server1='dbname=userdb_p0 host=127.0.0.1 port=6000',<br />
server2='dbname=userdb_p1 host=127.0.0.1 port=6000',<br />
server3='dbname=userdb_p2 host=127.0.0.1 port=6000',<br />
server4='dbname=userdb_p3 host=127.0.0.1 port=6000',<br />
connection_lifetime=3600<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER userdb;<br />
<br />
select * from pg_get_remote_connection_info('userdb');<br />
option | value <br />
---------------------+-------------------------------------------<br />
server1 | dbname=userdb_p0 host=127.0.0.1 port=6000<br />
server2 | dbname=userdb_p1 host=127.0.0.1 port=6000<br />
server3 | dbname=userdb_p2 host=127.0.0.1 port=6000<br />
server4 | dbname=userdb_p3 host=127.0.0.1 port=6000<br />
connection_lifetime | 3600<br />
(5 rows)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-11&diff=3451CommitFest 2008-112008-11-10T13:20:21Z<p>Martin.pihlak: </p>
<hr />
<div>__TOC__<br />
<br />
This is the page for the CommitFest starting '''2008 November'''.<br />
<br />
Managers for this CommitFest are Josh Berkus (josh-at-agliodbs-com) and Dave Page (dpage-at-pgadmin-org).<br />
<br />
{{CommitFestCurrent}}<br />
<br />
== Pending patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
|-<br />
| colspan="4" |<br />
=== SE-PostgreSQL and related ===<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei}}<br />
{{comment|Robert Haas|{{messageLink|48F71E36.9010203@ak.jp.nec.com|latest version}}, now with 6 patches}}<br />
{{comment|KaiGai|[[SEPostgreSQL]] is a draft of comprehensive document}}<br />
{{comment|KaiGai|{{messageLink|49180B32.5030308@ak.jp.nec.com|The latest patches to be reviewed (r1206)}}}}<br />
<br />
{{patch|20080901063855.GJ16005@tamriel.snowman.net|Column-level Permissions|Stephen Frost|status=Pending Review|reviewers=Markus Wanner}}<br />
{{comment|Stephen Frost|Updated patch {{messageLink|20080902221823.GL16005@tamriel.snowman.net|here}}}}<br />
{{review|48DB48AC.5010400@bluegap.ch|Markus Wanner|Awaiting updated patch.}}<br />
{{comment|Stephen Frost|Updated patch, again, {{messageLink|20081102034517.GR4452@tamriel.snowman.net|here}}}}<br />
{{comment|Stephen Frost|Updated patch, fixes case where unprivileged user can get row count, {{messageLink|20081102131332.GU4452@tamriel.snowman.net|here}}}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Recovery, Replication, Hot Standby ===<br />
<br />
{{patch|1220213074.4371.173.camel@ebony.2ndQuadrant|Infrastructure changes for recovery|status=Pending Review|Simon Riggs|reviewers=Tom Lane, Heikki Linnakangas}} <br />
{{comment|sriggs| important patch for other work}}<br />
{{comment|tgl|some comments {{messageLink|1905.1220895241@sss.pgh.pa.us|here}}}}<br />
{{comment|tgl|updated patch {{messageLink|1221080797.3913.768.camel@ebony.2ndQuadrant|here}}, still being tested}}<br />
{{comment|tgl|Simon found {{messageLink|1221725145.3913.2315.camel@ebony.2ndQuadrant|some issues}}}}<br />
{{comment|tgl|{{messageLink|1222184541.4445.400.camel@ebony.2ndQuadrant|patch v7}} here}}<br />
{{comment|tgl|it's still got {{messageLink|28973.1222381719@sss.pgh.pa.us|issues}}}}<br />
{{comment|Robert Haas|{{messageLink|1222815151.4445.1397.camel@ebony.2ndQuadrant|patch v8}} here}}<br />
{{comment|Robert Haas|{{messageLink|1223472898.4747.310.camel@ebony.2ndQuadrant|patch v9}} here, in response to {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's review}}}}<br />
{{comment|sriggs|some issues overlooked, fixed as part of Hot Standby patch only at present}}<br />
{{comment|sriggs|do we want this split out again as a separate patch for easier review?}}<br />
<br />
{{patch|1225557138.3971.673.camel@ebony.2ndQuadrant|Hot Standby - queries during archive recovery|status=Pending Review|Simon Riggs}}<br />
{{comment|sriggs| v5d now available, fixing all Mark's reported issues. Main parts are fully reviewable}}<br />
{{comment|sriggs| Wiki contains dynamically updated list of outstanding items [[Hot_Standby]] }}<br />
<br />
{{patch|1223472186.4747.301.camel@ebony.2ndQuadrant|pg_stop_backup wait bug fix|Simon Riggs}}<br />
{{comment|Robert Haas|sriggs extracted this from recovery infrastructure patch per {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's suggestion}}}}<br />
<br />
{{patch|1220174867.4371.107.camel@ebony.2ndQuadrant|rmgr hooks and contrib/rmgr_hook|status=Waiting on dependencies|Simon Riggs}} <br />
{{comment|sriggs| deferrable, if required}}<br />
{{comment|tgl|I think the plan is for this to wait till "infrastructure" patch goes in}}<br />
<br />
{{patch|3f0b79eb0810310436w360f0afdy76ff1499b177ce0d@mail.gmail.com|Synchronous log-shipping replication|Masao Fujii|reviewers=Heikki Linnakangas, Simon Riggs}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811040404r799d3170v5bb9f201000f1771@mail.gmail.com|signal handling patch v2}} here}}<br />
{{comment|fujii|{{messageLink|3f0b79eb0811050617o3237130awb4aec1d3a2daacab@mail.gmail.com|walsender process patch v1}} here}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Upgrade-in-place and related issues === <br />
<br />
{{patch|490B7C1B.8050408@sun.com|In-place online upgrade|status=Waiting for new version|Zdenek Kotala|reviewers=Robert Haas}}<br />
{{comment|Zdenek Kotala|This patch requires "htup and bufpage API clean up" and "HeapTuple version extension" patches. Git repository is [http://git.postgresql.org here] }}<br />
{{review|603c8f070811022022x582a9cbdp60798a6b87910edf@mail.gmail.com|Robert Haas|preliminary comments, still need a clean diff}}<br />
<br />
{{patch|48F1FC7E.1060406@sun.com|Extending pg_class info + more flexible TOAST chunk size|Zdenek Kotala|reviewers=Robert Haas|status=Waiting for new version}}<br />
{{comment|tgl|seems it'd be better to make TOAST chunks work like {{messageLink|490AB654.6040409@enterprisedb.com|this}}}}<br />
<br />
{{patch|4909DFCE.1000702@sun.com|HeapTuple version extension + code cleanup|Zdenek Kotala|reviewers=Robert Haas|status=Waiting for new version}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== SQL language features ===<br />
<br />
{{patch|e08cc0400810270912u49a6ec83vc23984c01f368f76@mail.gmail.com|Window Functions|Hitoshi Harada|reviewers=Heikki Linnakangas, David Rowley}}<br />
{{comment|Hitoshi Harada|updated patch is {{messageLink|e08cc0400810310721l22a6bb7kb6a300ce66443806@mail.gmail.com|here}}}}<br />
{{comment|Hitoshi Harada|the latest patch is {{messageLink|e08cc0400811070746p43553f10s6bb09e98b7eafc3b@mail.gmail.com|here}}}}<br />
<br />
{{patch|162867790810170316l4eeecb0bq321dd771f8f4e661@mail.gmail.com|grouping sets|status=WIP|Pavel Stehule|reviewers=Ibrar Ahmed}}<br />
{{comment|Pavel Stehule| doc and notes [[Grouping Sets]]}}<br />
<br />
{{patch|162867790810260428p56d16352qa1ec5c4c5330f25c@mail.gmail.com|default values for function's parameters|Pavel Stehule|reviewers=Peter Eisentraut|status=WIP}}<br />
{{comment|Pavel Stehule| fix known bugs, currently only doc should be finished}}<br />
<br />
{{patch|603c8f070808070503jd7be083kcce3e16345affb08@mail.gmail.com|add columns via CREATE OR REPLACE VIEW|Robert Haas|reviewers=Bernd Helmle}}<br />
{{comment|Robert Haas|some further justification of the proposed design {{messageLink|603c8f070808070956t1ab98dcdr933575eb096e4c28@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|questions about how to move forward {{messageLink|603c8f070810031839y7ce9a852o86effbab9fd6dd9b@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|a {{messageLink|482096EC.3000805@dunslane.net|similar feature request}} from Andrew Dunstan}}<br />
<br />
{{patch|48EFA13C.2060407@frogthinker.org|Prepared transactions and temp tables|Emmanuel Cecchet|reviewers=Heikki Linnakangas}}<br />
{{comment|tgl|new patch version {{messageLink|4914CD14.2060608@frogthinker.org|here}}}}<br />
<br />
{{patch|4909726F.8000800@gmx.net|TABLE command|Peter Eisentraut|status=Waiting on author|reviewers=Unicron, Robert Haas}}<br />
{{comment|Unicron|Patch {{messageLink|850603.14426.qm@web62408.mail.re1.yahoo.com|works per specification}}}}<br />
{{review|603c8f070811081050k79926d12x6547ae72abaa41af@mail.gmail.com|Robert Haas|wrong non-terminal, needs doc and psql updates}}<br />
<br />
{{patch|490AFC08.8040500@Sun.COM|Distinct types|Peter Eisentraut|status=Waiting on author}}<br />
{{comment|Bernd Helmle|Patch needs further work regarding {{messageLink|17750.1225571886@sss.pgh.pa.us|indexing}}}}<br />
{{comment|tgl|I don't think the {{messageLink|21942.1226084284@sss.pgh.pa.us|type-system behavior}} has been thought through properly}}<br />
<br />
{{patch|2849137C693B65CC8E86411C@imhotep.credativ.de|Automatic view update rules|status=WIP|Bernd Helmle|reviewers=Unicron}}<br />
{{comment|Bernd Helmle|New version with RETURNING support {{messageLink|94CF655A8D0DC7D5B4B81D8B@imhotep.credativ.de|here}}}}<br />
<br />
{{patch|1225543926.8122.14.camel@huvostro|Enable pl/python to return records based on multiple OUT params|status=Waiting on author|Hannu Krosing}}<br />
{{comment|Robert Haas|Hannu is {{messageLink|1225781532.7597.19.camel@huvostro|working on a new version}}}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Datatypes ===<br />
<br />
{{patch|48E4A30C.3000503@cheapcomplexdevices.com|status=Waiting on Author|ISO 8601 interval literal input and output|Ron Mayer|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|The initial (2003) version of this patch along with a thread which explains the feature a bit more can be found [http://archives.postgresql.org/pgsql-patches/2003-09/msg00103.php here].}}<br />
{{comment|Robert Haas|{{messageLink|490BA342.7010300@cheapcomplexdevices.com|latest version}}}}<br />
{{review|37ed240d0811050750v11726fd1of441646f87b583da@mail.gmail.com|BJ|Code style and documentation suggestions}}<br />
{{comment|Ron Mayer|Update here [http://0ape.com/postgres_interval_patches/ here] that fixes style & docs; as well as a bug where the ISO8601 spec wasn't quite followed (an optional field was treated as required by previous patches).}}<br />
{{review|37ed240d0811062058n752c3880kb04feb85e355b524@mail.gmail.com|BJ|Query behaviour of 'P0001', final doc cleanup suggestions}}<br />
{{comment|Ron Mayer|Update here [http://0ape.com/postgres_interval_patches/ here] that fixes 'P0001' and updated docs.}}<br />
{{comment|tgl|patch will need some work to sync with what I changed in the base IntervalStyle patch}}<br />
<br />
{{patch|48CEDE68.7090501@cheapcomplexdevices.com|Interval rounding consistency|Ron Mayer|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|Patch 3 [http://0ape.com/postgres_interval_patches/ here] refactors the interval code to remove much of the copy&paste in DecodeInterval and EncodeInterval with the side effect of making interval rounding more consistent between styles. This patch applies on top of the IntervalStyle patch and the ISO 8601 Interval patch.}}<br />
<br />
{{patch|20952F54-6730-49D8-99A3-1834697790B5@decibel.org|array_length|Jim C. Nasby|reviewers=Peter Eisentraut}}<br />
{{comment|Robert Haas|I have {{messageLink|603c8f070811062006q4f20b2bq179d4d2ffec65690@mail.gmail.com|reimplemented this in C}}}}<br />
<br />
{{patch|603c8f070810151933p445978b3td481a5422a2aebf4@mail.gmail.com|array_agg/array_accum|Robert Haas|reviewers=Peter Eisentraut}}<br />
{{comment|Robert Haas|{{messageLink|1225045937.4434.21.camel@localhost.localdomain|another version}} and {{messageLink|1225682527.1375.150.camel@jdavis|another one}} from Jeff Davis}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Indexes ===<br />
<br />
{{patch|490B07BA.6030109@sigaev.ru|GIN fast insert|Teodor Sigaev, Oleg Bartunov|reviewers=Jeff Davis}}<br />
<br />
{{patch|490B3752.3010800@sigaev.ru|B-Tree emulation for GIN|status=WIP|Teodor Sigaev, Oleg Bartunov|reviewers=Jeff Davis}}<br />
<br />
{{patch|20081101000154.GO27872@fune|On-disk bitmap indexes|status=WIP|Gabriele Bartolini, Gianni Ciolli|reviewers=Greg Stark (more welcome!)}}<br />
{{review|49130E72.1000803@sigaev.ru|Teodor Sigaev|several bugs}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Performance ===<br />
<br />
{{patch|6EEA43D22289484890D119821101B1DF2C1683@exchange20.mercury.ad.ubc.ca|Improve Performance of Multi-Batch Hash Join for Skewed Data Sets|Ramon Lawrence/Bryce Cutt|reviewers=Joshua Tolley}}<br />
{{comment|Joshua Tolley|[http://archives.postgresql.org/pgsql-hackers/2008-11/msg00286.php] reports backend crash}}<br />
{{comment|tgl|updated patch {{messageLink|1924d1180811051606w19aaf30du589e8ea10ea5534d@mail.gmail.com|here}}}}<br />
<br />
{{patch|4909B326.507@enterprisedb.com|Optimizing COPY with memchr()|Heikki Linnakangas|status=WIP|reviewers=Robert Haas}}<br />
{{comment|tgl|does this really need any more review at this point?}}<br />
{{comment|Robert Haas|asked author for {{messageLink|603c8f070811081745v410d2ff5o4bd107d7fbb440f3@mail.gmail.com|a status update}}}}<br />
<br />
{{patch|87ljw5c0lx.fsf@oxford.xeocode.com|posix_fadvise|Gregory Stark}}<br />
<br />
{{patch|a778a7260810280033n43f70d36x8c437eacf9a5461e@mail.gmail.com|Proposal of PITR performance improvement|Koichi Suzuki|reviewers=Simon Riggs}}<br />
<br />
{{patch|36e682920811021349h7202bdecpd7a45c8a8038465e@mail.gmail.com|Hash Join-Filter Pruning using Bloom Filters|status=WIP|Jonah Harris|reviewers=Kurt Harriman}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Improving admin experience ===<br />
<br />
{{patch|4905AE17.7090305@enterprisedb.com|Visibility map, partial vacuums|status=WIP|Heikki Linnakangas}}<br />
<br />
{{patch|20081029183248.GE4331@alvh.no-ip.org|Block-level CRC checks|Alvaro Herrera|status=WIP}}<br />
{{comment|alvherre|{{messageLink|20081107191140.GE5507@alvh.no-ip.org|updated patch}} here}}<br />
<br />
{{patch|c2ee6dbd0810100553gd328275ue2eb6e14bee70a8@mail.gmail.com|adding VERBOSE option to CLUSTER|Jim Cox|reviewers=Peter Eisentraut}}<br />
<br />
{{patch|a301bfd90810310750pf108c69x36499546f406650f@mail.gmail.com|Auto Partitioning Patch|Nikhil Sontakke|reviewers=Jaime Casanova}}<br />
<br />
{{patch|1223379173.4747.145.camel@ebony.2ndQuadrant|Reducing some DDL Locks to ShareLock|status=Pending Review|Simon Riggs|reviewers=Tom Lane}} <br />
{{comment|tgl|{{messageLink|1223404726.4747.249.camel@ebony.2ndQuadrant|v6 patch here}}}}<br />
{{comment|sriggs|agreed rework to implement pg_domain constraint, but the main patch still needs review}}<br />
{{comment|tgl|I think we'd decided to pass on the pg_constraint restructuring, at least for now}}<br />
{{comment|tgl|partially applied, what's left is {{messageLink|17459.1226279911@sss.pgh.pa.us|here}}}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Connection management ===<br />
<br />
{{patch|48FC7E84.3080702@hagander.net|SSL cleanups/hostname verification|Magnus Hagander|reviewers=Alex Hunsaker}}<br />
<br />
{{patch|49009D67.4040202@hagander.net|clientcert option for pg_hba|Magnus Hagander}}<br />
<br />
{{patch|49076F39.1080502@hagander.net|regexp support in usermaps|Magnus Hagander|reviewers=Gianni Colli}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Contrib modules ===<br />
<br />
{{patch|20081106171139.8D21.52131E4D@oss.ntt.co.jp|contrib infrastructures|Martin Pihlak, Takahiro Itagaki|reviewers=Jeff Davis, Matthew Wetmore}}<br />
{{comment|Itagaki|contains {{messageLink|490A00A8.7050708@gmail.com|QueryDesc}}, {{messageLink|20081009165157.9BE4.52131E4D@oss.ntt.co.jp|explain}} and {{messageLink|20081027171917.ADD6.52131E4D@oss.ntt.co.jp|hooks}}}}<br />
<br />
{{patch|20081009165157.9BE4.52131E4D@oss.ntt.co.jp|contrib/auto_explain|Takahiro Itagaki|reviewers=Jeff Davis}}<br />
{{comment|Itagaki|{{messageLink|20081110173232.7F2B.52131E4D@oss.ntt.co.jp|latest patch versions}}}}<br />
<br />
{{patch|20081011172450.3402.52131E4D@oss.ntt.co.jp|contrib/pg_stat_statements|Takahiro Itagaki|reviewers=Matthew Wetmore}}<br />
{{comment|Itagaki|{{messageLink|20081027171917.ADD6.52131E4D@oss.ntt.co.jp|latest patch versions}}}}<br />
{{comment|Itagaki|{{messageLink|1d709ecc0811011343lf65f58fjb2e96194f4c2ecc5@mail.gmail.com|comments}} from Vladimir}}<br />
<br />
{{patch|e4ccc24e0810222010p12bae2f4xa3a11cb2bc51bd89@mail.gmail.com|pg_standby support for compressed segments|Charles Duffy|reviewers=Simon Riggs}}<br />
{{comment|Simon Riggs|Deferring review for a few weeks until we get a better picture of streaming replication requirements for 8.4}}<br />
<br />
{{patch|Pine.GSO.4.64.0811012101220.17619@westnet.com|Simple postgresql.conf wizard|Greg Smith|reviewers=Josh Berkus}}<br />
<br />
|-<br />
| colspan="4" |<br />
=== Clients ===<br />
<br />
{{patch|200810271936.m9RJaGW09544@momjian.us|libpq callback unregistration|Bruce Momjian|reviewers=Magnus Hagander}}<br />
{{comment|Magnus|Needs more work, comments {{messageLink|490EEF2D.2050703@hagander.net|here}}}}<br />
{{comment|alvherre|Bruce posted a {{messageLink|200811050502.mA552TJ20677@momjian.us|new version}}, but it still {{messageLink|20081107201029.GF5507@alvh.no-ip.org|needs some work}}}}<br />
<br />
{{patch|48F04B7C.3080303@benedekl.tvnetwork.hu|pg_dump roles support|Benedek Laszlo|reviewers=Ibrar Ahmed|Status=Waiting for Author}}<br />
{{comment|alvherre|there's an {{messageLink|4912FA4E.1090000@benedekl.tvnetwork.hu|updated patch}}, and some extra {{messageLink|20081107202000.GG5507@alvh.no-ip.org|comments}}}}<br />
<br />
{{patch|490878AC.1@dunslane.net|parallel restore|status=WIP|Andrew Dunstan|reviewers=Kenneth Marshall}}<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
=== Miscellaneous ===<br />
<br />
{{patch|03c301c91737$be5a2a30$0e01a8c0@IBMC9A0F63B40D|Solve a problem of LC_TIME of windows|Hiroshi Saito}}<br />
{{comment|tgl|updated version {{messageLink|2C940A1672E743439355545C5DB15786@HIRO57887DE653|here}}}}<br />
{{comment|itagaki|comments and updated version {{messageLink|20081104094301.7EE8.52131E4D@oss.ntt.co.jp|here}}}}<br />
<br />
{{patch|BLU110-W38CE0A22D467A8C3D9736CFF540@phx.gbl|Support PLUGINS lines in Makefiles, similar to MODULES|Asif Naeem}}<br />
{{comment|Dave Page|This doesn't work with the edb-debugger plugin, which is the only such plugin around AFAIK. It needs to ignore comments on the PLUGINS line, and handle multiple targets (plugin_debugger, pldbgapi, targetinfo etc). Not sure if we want that complexity though.}}<br />
{{comment|Heikki|Unix-makefile version: {{messageLink|BLU110-W57823CEB7DC113354471EFF3B0@phx.gbl|here}}}}<br />
<br />
{{patch|48F53EC0.3020004@timbira.com|autovacuum and reloption|status=WIP|Euler Taveira de Oliveira|reviewers=Alvaro Herrera}}<br />
<br />
{{patch|49097338.2070700@gmail.com|SQL/MED compatible connection manager|Martin Pihlak|status=WIP}}<br />
{{comment|Martin Pihlak|Updated patch {{messageLink|49142C02.8020706@gmail.com|here}}}}<br />
<br />
{{patch|20081029164000.GL27466@fetter.org|pre-MED|David Fetter|reviewers=Alex Hunsaker|status=Waiting on author}}<br />
{{comment|David Fetter|Updated patch {{messageLink|20081031144852.GF15545@fetter.org|here}}}}<br />
{{review|34d269d40811031902p1d73d177w9f2e721ae169e8be@mail.gmail.com|alexhun|few questions and tgl had some constructive {{messageLink|24867.1225819435@sss.pgh.pa.us|comments}}}}<br />
<br />
{{patch|f205bb120810280833x340324d3m19a4f8aa65d822b@mail.gmail.com|FAQ_Solaris 1.28 to spanish|Emanuel CALVO FRANCO|reviewers=Peter Eisentraut}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Committed patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|20080803.114711.73374027.t-ishii@sraoss.co.jp|Common Table Expressions|Yoshiyuki Asaba|status=Committed 2008-10-04|reviewers=Jeff Davis}}<br />
{{comment|David Fetter|README is {{messageLink|20080818.163852.105172778.t-ishii@sraoss.co.jp|here.}}}}<br />
{{comment|David Fetter|Git repository is [http://git.postgresql.org/git/~davidfetter/cte/.git here.]}}<br />
{{comment|David Fetter|[[CTEReadme]]}}<br />
{{comment|David Fetter|[[CTESQLStandard| Fair Use from the draft SQL:2008 standard (WIP)]]}}<br />
{{review|13449.1221589943@sss.pgh.pa.us|tgl|needs a good bit of work yet}}<br />
<br />
{{patch|Pine.GSO.4.64.0809152349440.19910@westnet.com|Add default_val to pg_settings|status=Committed 2008-10-06|Greg Smith|reviewers=Simon Riggs,Magnus Hagander}}<br />
<br />
{{patch|20081016102603.897D.52131E4D@oss.ntt.co.jp|Noisy _dosmaperror|status=Committed 2008-10-16|Takahiro Itagaki|reviewers=Tom Lane}}<br />
<br />
{{patch|b4e5ce320810151918g2acf69ebh9f80f4f2e1c203a0@mail.gmail.com|Memory leak on hashed agg rescan|status=Committed 2008-10-16|Neil Conway|reviewers=Tom Lane}}<br />
{{review|10455.1224160007@sss.pgh.pa.us|Tom Lane|move some logic to separate function}}<br />
<br />
{{patch|1223383838.4747.154.camel@ebony.2ndQuadrant|Atomic subtransaction commit|status=Committed 2008-10-20|Simon Riggs|reviewers=Alvaro Herrera}} <br />
<br />
{{patch|3327.1224535092@sss.pgh.pa.us|add placeholder variables to planner|status=Committed 2008-10-22|Tom Lane}}<br />
<br />
{{patch|48E271C5.7010907@hagander.net|pg_hba options parsing|status=Committed 2008-10-23|Magnus Hagander|reviewers=Bruce Momjian}}<br />
{{comment|Robert Haas|{{messageLink|48F0DE8B.8030004@hagander.net|updated patch}}}}<br />
<br />
{{patch|48FC3994.8040809@hagander.net|libpq ssl -> clear fallback looses error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905D22D.9040001@hagander.net|better hba parsing error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905A1DE.5030102@hagander.net|remove crypt authentication|status=Committed 2008-10-28|Magnus Hagander}}<br />
<br />
{{patch|4905F515.3020208@gmx.net|Unicode escapes in literals|status=Committed 2008-10-29|Peter Eisentraut}}<br />
<br />
{{patch|490A138E.80100@enterprisedb.com|User defined I/O conversion casts|status=Committed 2008-10-31|Heikki Linnakangas}}<br />
<br />
{{patch|49085327.5010608@enterprisedb.com|Updating FSM on recovery|status=Committed 2008-10-31|Heikki Linnakangas}}<br />
<br />
{{patch|Pine.BSO.4.64.0810271955030.28764@leary.csoft.net|use new heap_(form/deform/modify)_tuple API|Kris Jurka|reviewers=Zdenek Kotala|status=Committed 2008-11-01}}<br />
{{comment|Zdenek Kotala| It seems OK. Needs apply also {{messageLink|Pine.BSO.4.64.0810281721500.6833@leary.csoft.net|pfree patch.}}}}<br />
<br />
{{patch|Pine.BSO.4.64.0810281622240.9851@leary.csoft.net|don't use MAKE_PTR/OFFSET for shmem pointers|Kris Jurka|reviewers=Tom Lane|status=Committed 2008-11-02}}<br />
<br />
{{patch|48C181D4.8030807@gmail.com|reducing statistics write overhead|Martin Pihlak|reviewers=Tom Lane|status=Committed 2008-11-02}}<br />
{{comment|Martin Pihlak|Latest patch {{messageLink|48C594D8.6050504@gmail.com|here}}}}<br />
<br />
{{patch|37ed240d0809030015u73b65b66v70fd76741317c6f5@mail.gmail.com|pg_typeof()|Brendan Jurd|reviewers=Kurt Harriman|status=Committed 2008-11-03}}<br />
{{comment|Kurt Harriman|{{messageLink|http://archives.postgresql.org/pgsql-hackers/2008-11/msg00080.php|Updated patch}} is ready to commit if there is no objection}}<br />
<br />
{{patch|Pine.BSO.4.64.0810081931240.11647@leary.csoft.net|Fixes for psql describeOneTableDetails|Kris Jurka|reviewers=Tom Lane|status=Committed 2008-11-03}}<br />
<br />
{{patch|48E22CF5.4050503@sun.com|PageGetTempPage cleanup |Zdenek Kotala|reviewers=Tom Lane|status=Committed 2008-11-03}}<br />
{{comment|Zdenek Kotala|Original discussion {{messageLink|4938.1217862947@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|603c8f070810092009s1312d30bxc854cdfb5d9fed7e@mail.gmail.com|Allow the UUID type to accept non-standard formats|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-03}}<br />
<br />
{{patch|603c8f070810101937n776c1e7cvd6a12345b0bbda28@mail.gmail.com|array_ndims|Robert Haas|reviewers=Peter Eisentraut|status=Committed 2008-11-04}}<br />
<br />
{{patch|603c8f070810282045g7fa6bdf9p53f03114d49643d7@mail.gmail.com|bulk inserts - keep most recent page pinned|Robert Haas|reviewers=Tom Lane|status=Committed 2008-11-06}}<br />
{{comment|Robert Haas|based on work by Simon Riggs: [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01080.php original idea],[http://archives.postgresql.org/pgsql-patches/2008-02/msg00140.php original patch], [http://archives.postgresql.org/pgsql-patches/2008-02/msg00154.php Tom Lane's comments]}}<br />
{{comment|Robert Haas|Tom's comments on my [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01276.php design proposal] are {{messageLink|17996.1225049097@sss.pgh.pa.us|here}}}}<br />
{{comment|Robert Haas|patch {{messageLink|603c8f070811011023n202aea33w4da13b7d14f74134@mail.gmail.com|v2}}, adjusting for Heikki's changes to the ReadBuffer interface}}<br />
<br />
{{patch|490394B7.6090503@lelarge.info|ALTER DATABASE SET TABLESPACE Statement|Guillaume Lelarge|reviewers=Bernd Helmle|status=Committed 2008-11-07}}<br />
{{comment|Bernd Helmle|Syntax discussion and updated version {{messageLink|C0F6602797884925406AB88F@imhotep.credativ.de|here}}}}<br />
{{comment|Guillaume Lelarge|Updated version with SET syntax {{messageLink|4910E46E.4010000@lelarge.info|here}}}}<br />
{{comment|Bernd Helmle|Updated version from Guillaume {{messageLink|4912C88A.2070808@lelarge.info|here}}}}<br />
{{comment|Guillaume Lelarge|Updated version {{messageLink|49140181.3000903@lelarge.info|here}}}}<br />
<br />
{{patch|0BD2E4E9-AF5A-4B4F-B546-027424EE8FAD@kineticode.com|Tests citext casts|David Wheeler|reviewers=<br />
Kenneth Marshall|status=Committed 2008-11-07}}<br />
<br />
{{patch|48D15471.6080305@cheapcomplexdevices.com|SQL Standard Interval output and IntervalStyle GUC|Ron Mayer|status=Committed 2008-11-08|reviewers=Brendan Jurd}}<br />
{{comment|Ron Mayer|Early updates {{messageLink|48D52E48.406@cheapcomplexdevices.com|here}}, {{messageLink|48E49BDC.4090402@cheapcomplexdevices.com|here}}, and [http://0ape.com/postgres_interval_patches/ here]. Mostly related to GUC changes.}}<br />
{{review|37ed240d0811032122u56db1959h91f53bbb9733c90d@mail.gmail.com|BJ|Bug in output, stylistic suggestions}}<br />
{{comment|the mailing list|Feedback from {{messageLink|19477.1225814409@sss.pgh.pa.us|Tom L}} and {{messageLink|49101C94.EE98.0025.0@wicourts.gov|Kevin G}} about mixed-sign intervals}}<br />
{{comment|Ron Mayer|Updated patch {{messageLink|4910B1DB.4000000.cheapcomplexdevices@com|here}} to fix -12:01:-30 bug and style suggestions from the review and to attempt to address feedback about mixed-sign intervals with doc updates.}}<br />
{{review|37ed240d0811042102q78df5b86t2ff2092a75d371d7@mail.gmail.com|BJ|One last typo in docs but otherwise all good; review complete}}<br />
{{review|28915.1226109473@sss.pgh.pa.us|Tom L|Tom pointed out issues with pg_dump and restore into databases with a different interval style}}<br />
{{comment|Ron Mayer|{{messageLink|4915AC0A.9070608@cheapcomplexdevices.com|Speculating}} if an analogy with standard_conforming_strings applies to how we can handle dump/restore.}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Returned with Feedback ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|1225010283.21241.33.camel@localhost.localdomain|new correlation metric|Jeff Davis|reviewers=Brendan Jurd|status=Pending rework}}<br />
<br />
{{patch|49086E4C.9030602@sun.com|htup and bufpage API clean up|Zdenek Kotala|reviewers=Robert Haas|status=Needs different approach}}<br />
{{comment|Zdenek Kotala|New version is {{messageLink|490875FA.4020709@sun.com|here}}}}<br />
{{review|603c8f070811031822q7d3b33f7x8576b7028f498cc4@mail.gmail.com|Robert Haas|proposed API seems too costly and fragile}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Round Robin Reviewers ==<br />
<br />
<br />
{| border="1" cellpadding="1" cellspacing="0" style="width: 60%; border-collapse: collapse; border: 1px solid #ccc; font-size: 90%;"<br />
|- style="background: #eee;"<br />
! width="30%" | Name<br />
!Status<br />
!Reviewing<br />
!Completed<br />
|-<br />
|Brendan Jurd || Available || 2 || 2<br />
|-<br />
|Jaime Casanova || Available || 1 || 1<br />
|-<br />
|Stephen Frost || Available 11/15 || 0 || 0<br />
|-<br />
|Jeff Davis || Available || 2 || 1<br />
|-<br />
|Greg Stark || Unknown || 1 || 0<br />
|-<br />
|Abhijit Menon-Sen || Unknown || 0 || 0<br />
|-<br />
|Alex Hunsaker || Available || 1 || 0<br />
|-<br />
|Markus Wanner || Cherry-picking || 1 || 0<br />
|-<br />
|Ibrar Ahmed || Available || 1 || 0<br />
|-<br />
|D'Arcy Cain || Unknown || 0 || 0<br />
|-<br />
|Kenneth Marshall || Available || 1 || 1<br />
|-<br />
|Robert Haas || Available || 1 || 4<br />
|-<br />
|Matthew Wetmore || Available || 1 || 0<br />
|-<br />
|Gianni Colli || Available || 1 || 0<br />
|-<br />
|"Unicron" || Available || 1 || 1<br />
|}</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3394SqlMedConnectionManager2008-11-07T11:12:23Z<p>Martin.pihlak: /* Examples */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host='remotehost', dbname='remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username='bob', password='secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username. In this version the privilege are checked for the supplied user.<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (user='bob', password='salakala');<br />
<br />
select * from pg_get_remote_connection_info('foodb');<br />
<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
<br />
ERROR: permission denied for foreign server foodb<br />
<br />
GRANT USAGE ON SERVER foodb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER "default"<br />
OPTIONS (tnsname='ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername='scott', passw0rd='tiger');<br />
GRANT USAGE ON SERVER bazdb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('bazdb', 'bob');<br />
<br />
option | value <br />
-----------+-------<br />
tnsname | ORCL<br />
lusername | scott<br />
passw0rd | tiger<br />
(3 rows)<br />
<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource='DBI:Excel:file=dbdtest.xls',<br />
attributes='{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER dbdtest;<br />
<br />
select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
option | value <br />
------------+----------------------------------<br />
datasource | DBI:Excel:file=dbdtest.xls<br />
attributes | {xl_vtbl => {TESTV => { ... } }}<br />
(2 rows)<br />
<br />
</pre><br />
<br />
===plproxy cluster===<br />
An example of how a plproxy cluster might be described. In reality 'default_fdw'<br />
would be replaced by the actual plproxy library.<br />
<pre><br />
<br />
CREATE FOREIGN DATA WRAPPER plproxy LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER userdb TYPE 'plproxy_cluster'<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (<br />
server='dbname=userdb_p0 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p1 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p2 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p3 host=127.0.0.1 port=6000',<br />
connection_lifetime=3600<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER userdb;<br />
<br />
select * from pg_get_remote_connection_info('userdb');<br />
option | value <br />
---------------------+-------------------------------------------<br />
server | dbname=userdb_p0 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p1 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p2 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p3 host=127.0.0.1 port=6000<br />
connection_lifetime | 3600<br />
(5 rows)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3393SqlMedConnectionManager2008-11-07T11:11:59Z<p>Martin.pihlak: /* "default" FDW */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host='remotehost', dbname='remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username='bob', password='secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username. In this version the privilege are checked for the supplied user.<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (user='bob', password='salakala');<br />
<br />
select * from pg_get_remote_connection_info('foodb');<br />
<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
<br />
ERROR: permission denied for foreign server foodb<br />
<br />
GRANT USAGE ON SERVER foodb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER "default"<br />
OPTIONS (tnsname='ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername='scott', passw0rd='tiger');<br />
GRANT USAGE ON SERVER bazdb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('bazdb', 'bob');<br />
<br />
option | value <br />
-----------+-------<br />
tnsname | ORCL<br />
lusername | scott<br />
passw0rd | tiger<br />
(3 rows)<br />
<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource='DBI:Excel:file=dbdtest.xls',<br />
attributes='{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER dbdtest;<br />
<br />
# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
option | value <br />
------------+----------------------------------<br />
datasource | DBI:Excel:file=dbdtest.xls<br />
attributes | {xl_vtbl => {TESTV => { ... } }}<br />
(2 rows)<br />
<br />
</pre><br />
<br />
===plproxy cluster===<br />
An example of how a plproxy cluster might be described. In reality 'default_fdw'<br />
would be replaced by the actual plproxy library.<br />
<pre><br />
<br />
CREATE FOREIGN DATA WRAPPER plproxy LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER userdb TYPE 'plproxy_cluster'<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (<br />
server='dbname=userdb_p0 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p1 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p2 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p3 host=127.0.0.1 port=6000',<br />
connection_lifetime=3600<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER userdb;<br />
<br />
# select * from pg_get_remote_connection_info('userdb');<br />
option | value <br />
---------------------+-------------------------------------------<br />
server | dbname=userdb_p0 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p1 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p2 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p3 host=127.0.0.1 port=6000<br />
connection_lifetime | 3600<br />
(5 rows)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3392SqlMedConnectionManager2008-11-07T11:11:40Z<p>Martin.pihlak: /* pgsql */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host='remotehost', dbname='remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username='bob', password='secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username. In this version the privilege are checked for the supplied user.<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (user='bob', password='salakala');<br />
<br />
select * from pg_get_remote_connection_info('foodb');<br />
<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
<br />
ERROR: permission denied for foreign server foodb<br />
<br />
GRANT USAGE ON SERVER foodb TO bob;<br />
<br />
select * from pg_get_remote_connection_info('foodb', 'bob');<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER "default"<br />
OPTIONS (tnsname='ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername='scott', passw0rd='tiger');<br />
GRANT USAGE ON SERVER bazdb TO bob;<br />
<br />
# select * from pg_get_remote_connection_info('bazdb', 'bob');<br />
<br />
option | value <br />
-----------+-------<br />
tnsname | ORCL<br />
lusername | scott<br />
passw0rd | tiger<br />
(3 rows)<br />
<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource='DBI:Excel:file=dbdtest.xls',<br />
attributes='{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER dbdtest;<br />
<br />
# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
option | value <br />
------------+----------------------------------<br />
datasource | DBI:Excel:file=dbdtest.xls<br />
attributes | {xl_vtbl => {TESTV => { ... } }}<br />
(2 rows)<br />
<br />
</pre><br />
<br />
===plproxy cluster===<br />
An example of how a plproxy cluster might be described. In reality 'default_fdw'<br />
would be replaced by the actual plproxy library.<br />
<pre><br />
<br />
CREATE FOREIGN DATA WRAPPER plproxy LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER userdb TYPE 'plproxy_cluster'<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (<br />
server='dbname=userdb_p0 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p1 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p2 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p3 host=127.0.0.1 port=6000',<br />
connection_lifetime=3600<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER userdb;<br />
<br />
# select * from pg_get_remote_connection_info('userdb');<br />
option | value <br />
---------------------+-------------------------------------------<br />
server | dbname=userdb_p0 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p1 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p2 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p3 host=127.0.0.1 port=6000<br />
connection_lifetime | 3600<br />
(5 rows)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3391SqlMedConnectionManager2008-11-07T11:10:36Z<p>Martin.pihlak: /* Examples */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host='remotehost', dbname='remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username='bob', password='secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username. In this version the privilege are checked for the supplied user.<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (user='bob', password='salakala');<br />
<br />
# select * from pg_get_remote_connection_info('foodb');<br />
<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
# select * from pg_get_remote_connection_info('foodb', 'bob');<br />
<br />
ERROR: permission denied for foreign server foodb<br />
<br />
GRANT USAGE ON SERVER foodb TO bob;<br />
<br />
# select * from pg_get_remote_connection_info('foodb', 'bob');<br />
option | value <br />
------------+--------------------------------------------------<br />
datasource | dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER "default"<br />
OPTIONS (tnsname='ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername='scott', passw0rd='tiger');<br />
GRANT USAGE ON SERVER bazdb TO bob;<br />
<br />
# select * from pg_get_remote_connection_info('bazdb', 'bob');<br />
<br />
option | value <br />
-----------+-------<br />
tnsname | ORCL<br />
lusername | scott<br />
passw0rd | tiger<br />
(3 rows)<br />
<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource='DBI:Excel:file=dbdtest.xls',<br />
attributes='{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER dbdtest;<br />
<br />
# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
option | value <br />
------------+----------------------------------<br />
datasource | DBI:Excel:file=dbdtest.xls<br />
attributes | {xl_vtbl => {TESTV => { ... } }}<br />
(2 rows)<br />
<br />
</pre><br />
<br />
===plproxy cluster===<br />
An example of how a plproxy cluster might be described. In reality 'default_fdw'<br />
would be replaced by the actual plproxy library.<br />
<pre><br />
<br />
CREATE FOREIGN DATA WRAPPER plproxy LIBRARY 'default_fdw';<br />
<br />
CREATE SERVER userdb TYPE 'plproxy_cluster'<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (<br />
server='dbname=userdb_p0 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p1 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p2 host=127.0.0.1 port=6000',<br />
server='dbname=userdb_p3 host=127.0.0.1 port=6000',<br />
connection_lifetime=3600<br />
);<br />
<br />
CREATE USER MAPPING FOR current_user SERVER userdb;<br />
<br />
# select * from pg_get_remote_connection_info('userdb');<br />
option | value <br />
---------------------+-------------------------------------------<br />
server | dbname=userdb_p0 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p1 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p2 host=127.0.0.1 port=6000<br />
server | dbname=userdb_p3 host=127.0.0.1 port=6000<br />
connection_lifetime | 3600<br />
(5 rows)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3358SqlMedConnectionManager2008-11-06T13:29:40Z<p>Martin.pihlak: /* SQL API */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host='remotehost', dbname='remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username='bob', password='secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username. In this version the privilege are checked for the supplied user.<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
<br />
test=# create foreign data wrapper dummy library 'default_fdw';<br />
CREATE FOREIGN DATA WRAPPER<br />
<br />
test=# create server foo type 'pgsql' version '8.4' foreign data wrapper dummy options (host='127.0.01', dbname=test);<br />
CREATE SERVER<br />
<br />
test=# create user mapping for martinp server foo options (user=bob,password=secret);<br />
CREATE USER MAPPING<br />
<br />
test=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+----------<br />
host | 127.0.01<br />
dbname | test<br />
user | bob<br />
password | secret<br />
(4 rows)<br />
<br />
-- pgsql wrapper<br />
<br />
test=# create foreign data wrapper pgsql library 'pgsql_fdw';<br />
CREATE FOREIGN DATA WRAPPER<br />
<br />
test=# create server bar foreign data wrapper pgsql options (host=localhost,port=5432,dbname=test);<br />
CREATE SERVER<br />
<br />
test=# create user mapping for current_user server bar options (username=test,password=test);<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
test=# create user mapping for current_user server bar options (user=test,password=test);<br />
CREATE USER MAPPING<br />
<br />
test=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+--------------------------------------------------------------<br />
datasource | host=localhost port=5432 dbname=test user=test password=test<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3348SqlMedConnectionManager2008-11-06T09:50:33Z<p>Martin.pihlak: /* Foreign data wrapper API */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host='remotehost', dbname='remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username='bob', password='secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validateOptionList(fdw, what, options) : Validate the generic options for the <tt>FDW</tt>, <tt>server</tt> or <tt>user mapping</tt>.<br />
<br />
<pre><br />
void<br />
validateOptionList(ForeignDataWrapper *fdw, GenericOptionFlags flags,<br />
List *options)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routine will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username.<br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
<br />
test=# create foreign data wrapper dummy library 'default_fdw';<br />
CREATE FOREIGN DATA WRAPPER<br />
<br />
test=# create server foo type 'pgsql' version '8.4' foreign data wrapper dummy options (host='127.0.01', dbname=test);<br />
CREATE SERVER<br />
<br />
test=# create user mapping for martinp server foo options (user=bob,password=secret);<br />
CREATE USER MAPPING<br />
<br />
test=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+----------<br />
host | 127.0.01<br />
dbname | test<br />
user | bob<br />
password | secret<br />
(4 rows)<br />
<br />
-- pgsql wrapper<br />
<br />
test=# create foreign data wrapper pgsql library 'pgsql_fdw';<br />
CREATE FOREIGN DATA WRAPPER<br />
<br />
test=# create server bar foreign data wrapper pgsql options (host=localhost,port=5432,dbname=test);<br />
CREATE SERVER<br />
<br />
test=# create user mapping for current_user server bar options (username=test,password=test);<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
test=# create user mapping for current_user server bar options (user=test,password=test);<br />
CREATE USER MAPPING<br />
<br />
test=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+--------------------------------------------------------------<br />
datasource | host=localhost port=5432 dbname=test user=test password=test<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3347SqlMedConnectionManager2008-11-06T09:47:40Z<p>Martin.pihlak: /* SQL syntax */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host='remotehost', dbname='remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username='bob', password='secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate FDW's<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username.<br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
<br />
test=# create foreign data wrapper dummy library 'default_fdw';<br />
CREATE FOREIGN DATA WRAPPER<br />
<br />
test=# create server foo type 'pgsql' version '8.4' foreign data wrapper dummy options (host='127.0.01', dbname=test);<br />
CREATE SERVER<br />
<br />
test=# create user mapping for martinp server foo options (user=bob,password=secret);<br />
CREATE USER MAPPING<br />
<br />
test=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+----------<br />
host | 127.0.01<br />
dbname | test<br />
user | bob<br />
password | secret<br />
(4 rows)<br />
<br />
-- pgsql wrapper<br />
<br />
test=# create foreign data wrapper pgsql library 'pgsql_fdw';<br />
CREATE FOREIGN DATA WRAPPER<br />
<br />
test=# create server bar foreign data wrapper pgsql options (host=localhost,port=5432,dbname=test);<br />
CREATE SERVER<br />
<br />
test=# create user mapping for current_user server bar options (username=test,password=test);<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
test=# create user mapping for current_user server bar options (user=test,password=test);<br />
CREATE USER MAPPING<br />
<br />
test=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+--------------------------------------------------------------<br />
datasource | host=localhost port=5432 dbname=test user=test password=test<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3345SqlMedConnectionManager2008-11-06T09:43:28Z<p>Martin.pihlak: /* Current implementation */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username.<br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
<br />
test=# create foreign data wrapper dummy library 'default_fdw';<br />
CREATE FOREIGN DATA WRAPPER<br />
<br />
test=# create server foo type 'pgsql' version '8.4' foreign data wrapper dummy options (host='127.0.01', dbname=test);<br />
CREATE SERVER<br />
<br />
test=# create user mapping for martinp server foo options (user=bob,password=secret);<br />
CREATE USER MAPPING<br />
<br />
test=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+----------<br />
host | 127.0.01<br />
dbname | test<br />
user | bob<br />
password | secret<br />
(4 rows)<br />
<br />
-- pgsql wrapper<br />
<br />
test=# create foreign data wrapper pgsql library 'pgsql_fdw';<br />
CREATE FOREIGN DATA WRAPPER<br />
<br />
test=# create server bar foreign data wrapper pgsql options (host=localhost,port=5432,dbname=test);<br />
CREATE SERVER<br />
<br />
test=# create user mapping for current_user server bar options (username=test,password=test);<br />
ERROR: Invalid option "username" to user mapping<br />
HINT: Valid user mapping options are: user, password<br />
<br />
test=# create user mapping for current_user server bar options (user=test,password=test);<br />
CREATE USER MAPPING<br />
<br />
test=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+--------------------------------------------------------------<br />
datasource | host=localhost port=5432 dbname=test user=test password=test<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3261SqlMedConnectionManager2008-11-03T21:15:06Z<p>Martin.pihlak: /* psql support */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username.<br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
* Need additional \dX commands for displaying remote connection information.<br />
* Tab completion for the new syntax.<br />
* Help<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3250SqlMedConnectionManager2008-11-03T13:17:19Z<p>Martin.pihlak: /* Privileges */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username.<br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
* It should be safe to allow GetRemoteConnectionInfo() to be called by non-superusers - the calling function uses an untrusted language and hence can only be deployed by superuser.<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3249SqlMedConnectionManager2008-11-03T13:01:29Z<p>Martin.pihlak: /* Privileges */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username.<br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() and pg_get_remote_connection_info() check the privileges of the supplied user.<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3248SqlMedConnectionManager2008-11-03T12:59:07Z<p>Martin.pihlak: </p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username.<br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===Privileges===<br />
<br />
{| border="1" align="center"<br />
!<br />
! superuser<br />
! SERVER owner<br />
! FDW USAGE<br />
! SERVER USAGE<br />
|-<br />
! CREATE FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! ALTER FDW<br />
| x<br />
|<br />
|<br />
|<br />
|-<br />
! DROP FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON FDW<br />
| x<br />
| <br />
| <br />
| <br />
|-<br />
! CREATE SERVER<br />
| x<br />
| <br />
| x<br />
| <br />
|-<br />
! ALTER SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GRANT USAGE ON SERVER<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! CREATE USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! ALTER USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! DROP USER MAPPING<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
! GetRemoteConnectionInfo()<br />
| x<br />
| x<br />
| <br />
| x<br />
|-<br />
! pg_get_remote_connection_info()<br />
| x<br />
| x<br />
| <br />
| <br />
|-<br />
|}<br />
<br />
<br />
* For now only superuser can create a <tt>foreign data wrappers</tt>. Disallow FDW owner change.<br />
* Grant USAGE on FDW essentially grants the right to create servers on that FDW.<br />
* FDW USAGE is not required for using the SERVER.<br />
* GetRemoteConnectionInfo() checks the privileges of the user id supplied to it.<br />
<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3223SqlMedConnectionManager2008-11-02T21:18:11Z<p>Martin.pihlak: /* SQL API */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* Privilege checks and user mapping lookups are done with current effective user id. In some cases a session user or a role might be desired instead. For this purpouse we provide a 2 parameter version of the function, which also accepts a username.<br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-11&diff=3164CommitFest 2008-112008-10-31T16:02:42Z<p>Martin.pihlak: /* Pending patches */</p>
<hr />
<div>__TOC__<br />
<br />
This is the page for the CommitFest starting '''2008 November'''.<br />
<br />
{{CommitFestOpen}}<br />
<br />
== Pending patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei|reviewers=Peter Eisentraut, Abhijit Menon-Sen}}<br />
{{comment|Peter|checking with Solaris engineers about compatibility with Solaris TX; will continue review throughout August}}<br />
{{comment|KaiGai|{{messageLink|488F0C02.4020708@ak.jp.nec.com|latest patch versions}}}}<br />
{{comment|KaiGai|{{messageLink|48BA12F4.1090201@kaigai.gr.jp|latest patch versions}}}}<br />
{{comment|Robert Haas|KaiGai's latest version is {{messageLink|48F46606.4080207@ak.jp.nec.com|r1120}}}}<br />
{{comment|Robert Haas|{{messageLink|48F71E36.9010203@ak.jp.nec.com|latest version}}, now with 6 patches}}<br />
{{comment|KaiGai|[[SEPostgreSQL]] can be a comprehensive documentation (now in progress)}}<br />
{{comment|KaiGai|{{messageLink|490AD10A.6020902@ak.jp.nec.com|latest patches (r1168)}}}}<br />
<br />
<br />
{{patch|1220213074.4371.173.camel@ebony.2ndQuadrant|Infrastructure changes for recovery|status=Pending Review|Simon Riggs|reviewers=Tom Lane, Heikki Linnakangas}} <br />
{{comment|sriggs| important patch for other work}}<br />
{{comment|tgl|some comments {{messageLink|1905.1220895241@sss.pgh.pa.us|here}}}}<br />
{{comment|tgl|updated patch {{messageLink|1221080797.3913.768.camel@ebony.2ndQuadrant|here}}, still being tested}}<br />
{{comment|tgl|Simon found {{messageLink|1221725145.3913.2315.camel@ebony.2ndQuadrant|some issues}}}}<br />
{{comment|tgl|{{messageLink|1222184541.4445.400.camel@ebony.2ndQuadrant|patch v7}} here}}<br />
{{comment|tgl|it's still got {{messageLink|28973.1222381719@sss.pgh.pa.us|issues}}}}<br />
{{comment|Robert Haas|{{messageLink|1222815151.4445.1397.camel@ebony.2ndQuadrant|patch v8}} here}}<br />
{{comment|Robert Haas|{{messageLink|1223472898.4747.310.camel@ebony.2ndQuadrant|patch v9}} here, in response to {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's review}}}}<br />
<br />
{{patch|1220174867.4371.107.camel@ebony.2ndQuadrant|rmgr hooks and contrib/rmgr_hook|status=Waiting on author|Simon Riggs}} <br />
{{comment|sriggs| deferrable, if required}}<br />
{{comment|tgl|I think the plan is for this to wait till "infrastructure" patch goes in}}<br />
<br />
{{patch|37ed240d0809030015u73b65b66v70fd76741317c6f5@mail.gmail.com|pg_typeof()|Brendan Jurd}}<br />
<br />
{{patch|48C181D4.8030807@gmail.com|reducing statistics write overhead|Martin Pihlak}}<br />
{{comment|Martin Pihlak|Latest patch {{messageLink|48C594D8.6050504@gmail.com|here}}}}<br />
<br />
{{patch|BLU110-W38CE0A22D467A8C3D9736CFF540@phx.gbl|Support PLUGINS lines in Makefiles, similar to MODULES|Asif Naeem}}<br />
{{comment|Dave Page|This doesn't work with the edb-debugger plugin, which is the only such plugin around AFAIK. It needs to ignore comments on the PLUGINS line, and handle multiple targets (plugin_debugger, pldbgapi, targetinfo etc). Not sure if we want that complexity though.}}<br />
{{comment|Heikki|Unix-makefile version: {{messageLink|BLU110-W57823CEB7DC113354471EFF3B0@phx.gbl|here}}}}<br />
<br />
<br />
{{patch|48D15471.6080305@cheapcomplexdevices.com|SQL Standard Interval output and IntervalStyle GUC|Ron Mayer}}<br />
{{comment|Ron Mayer|<br />
An update {{messageLink|48D52E48.406@cheapcomplexdevices.com|here}} fixed <br />
some bugs in GUC setting. <br />
Another update {{messageLink|48E49BDC.4090402@cheapcomplexdevices.com|here}}, <br />
brought up-to-date with HEAD}}<br />
{{comment|Ron Mayer|Brought up-to-date with head [http://0ape.com/postgres_interval_patches/ here]. Now allows setting IntervalStyle through an environment variable because pg_regress had set interval styles (as a side-effect of setting DateStyles) through the environment, some minor cleanup.}}<br />
<br />
{{patch|48E4A30C.3000503@cheapcomplexdevices.com|ISO 8601 interval literal input and output|Ron Mayer}}<br />
{{comment|Ron Mayer|Note that this patch doesn't apply directly to HEAD, but depends on the {{messageLink|48E49BDC.4090402@cheapcomplexdevices.com|IntervalStyle GUC patch}} to be applied first.}}<br />
{{comment|Ron Mayer|The initial (2003) version of this patch along with a thread which explains the feature a bit more can be found [http://archives.postgresql.org/pgsql-patches/2003-09/msg00103.php here].}}<br />
{{comment|Ron Mayer|An update [http://0ape.com/postgres_interval_patches/ here]. Cleaned up code and added regression tests.}}<br />
<br />
{{patch|48CEDE68.7090501@cheapcomplexdevices.com|Interval rounding consistency|Ron Mayer}}<br />
{{comment|Ron Mayer|Patch 3 [http://0ape.com/postgres_interval_patches/ here] refactors the interval code to remove much of the copy&paste in DecodeInterval and EncodeInterval with the side effect of making interval rounding more consistent between styles. This patch applies on top of the IntervalStyle patch and the ISO 8601 Interval patch.}}<br />
<br />
<br />
{{patch|03c301c91737$be5a2a30$0e01a8c0@IBMC9A0F63B40D|Solve a problem of LC_TIME of windows|Hiroshi Saito}}<br />
<br />
{{patch|20080901063855.GJ16005@tamriel.snowman.net|Column-level Permissions|Stephen Frost|status=WIP|reviewers=Markus Wanner}}<br />
{{comment|Stephen Frost|Updated patch {{messageLink|20080902221823.GL16005@tamriel.snowman.net|here}}}}<br />
{{review|48DB48AC.5010400@bluegap.ch|Markus Wanner|Awaiting updated patch.}}<br />
<br />
{{patch|0BD2E4E9-AF5A-4B4F-B546-027424EE8FAD@kineticode.com|Tests citext casts|David Wheeler}}<br />
<br />
{{patch|48E22CF5.4050503@sun.com|PageGetTempPage cleanup |Zdenek Kotala}}<br />
{{comment|Zdenek Kotala|Original discussion {{messageLink|4938.1217862947@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|603c8f070808070503jd7be083kcce3e16345affb08@mail.gmail.com|add columns via CREATE OR REPLACE VIEW|Robert Haas}}<br />
{{comment|Robert Haas|some further justification of the proposed design {{messageLink|603c8f070808070956t1ab98dcdr933575eb096e4c28@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|questions about how to move forward {{messageLink|603c8f070810031839y7ce9a852o86effbab9fd6dd9b@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|a {{messageLink|482096EC.3000805@dunslane.net|similar feature request}} from Andrew Dunstan}}<br />
<br />
{{patch|1223379173.4747.145.camel@ebony.2ndQuadrant|Reducing some DDL Locks to ShareLock|status=Pending Review|Simon Riggs}} <br />
{{comment|Robert Haas|{{messageLink|1722552592.7.1224882093461.JavaMail.root@spotone|ddl_lock_reduce.v4.patch}}}}<br />
<br />
{{patch|Pine.BSO.4.64.0810081931240.11647@leary.csoft.net|Fixes for psql describeOneTableDetails|Kris Jurka}}<br />
<br />
{{patch|1223472186.4747.301.camel@ebony.2ndQuadrant|pg_stop_backup wait bug fix|Simon Riggs}}<br />
{{comment|Robert Haas|sriggs extracted this from recovery infrastructure patch per {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's suggestion}}}}<br />
<br />
{{patch|20081009165157.9BE4.52131E4D@oss.ntt.co.jp|contrib/auto_explain|Takahiro Itagaki|}}<br />
<br />
{{patch|603c8f070810092009s1312d30bxc854cdfb5d9fed7e@mail.gmail.com|Allow the UUID type to accept non-standard formats|Robert Haas}}<br />
<br />
{{patch|603c8f070810101937n776c1e7cvd6a12345b0bbda28@mail.gmail.com|array_ndims|Robert Haas}}<br />
<br />
{{patch|48F04B7C.3080303@benedekl.tvnetwork.hu|pg_dump roles support|Benedek Laszlo}}<br />
<br />
{{patch|20081011172450.3402.52131E4D@oss.ntt.co.jp|contrib/pg_stat_statements|Takahiro Itagaki}}<br />
{{comment|Itagaki|{{messageLink|20081027171917.ADD6.52131E4D@oss.ntt.co.jp|latest patch versions}}}}<br />
<br />
{{patch|49078031.9030002@gmail.com|contrib/pg_stat_staments querydesc|Martin Pihlak}}<br />
{{comment|Martin Pihlak|Updated patch {{messageLink|490A00A8.7050708@gmail.com|here}}}}<br />
<br />
<br />
{{patch|c2ee6dbd0810100553gd328275ue2eb6e14bee70a8@mail.gmail.com|adding VERBOSE option to CLUSTER|Jim Cox}}<br />
<br />
{{patch|e08cc0400810270912u49a6ec83vc23984c01f368f76@mail.gmail.com|Window Functions|Hitoshi Harada|reviewers=Heikki Linnakangas}}<br />
{{comment|Harada|updated patch is {{messageLink|e08cc0400810310721l22a6bb7kb6a300ce66443806@mail.gmail.com|here}}}}<br />
<br />
{{patch|48F1FC7E.1060406@sun.com|Extending pg_class info + more flexible TOAST chunk size|Zdenek Kotala}}<br />
<br />
{{patch|48EFA13C.2060407@frogthinker.org|Transactions and temp tables|Emmanuel Cecchet|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|20952F54-6730-49D8-99A3-1834697790B5@decibel.org|array_length|Jim C. Nasby}}<br />
<br />
{{patch|603c8f070810151933p445978b3td481a5422a2aebf4@mail.gmail.com|array_agg|Robert Haas}}<br />
{{comment|Robert Haas|{{messageLink|27bbfebe0810151633q1aac3ea8v864bea997f3cc5ec@mail.gmail.com|another version}} from Ian Caulfield and {{messageLink|1225045937.4434.21.camel@localhost.localdomain|yet another}} from Jeff Davis}}<br />
<br />
{{patch|490878AC.1@dunslane.net|parallel restore|status=WIP|Andrew Dunstan}}<br />
<br />
{{patch|48F53EC0.3020004@timbira.com|autovacuum and reloption|status=WIP|Euler Taveira de Oliveira|reviewers=Alvaro Herrera}}<br />
<br />
{{patch|162867790810170316l4eeecb0bq321dd771f8f4e661@mail.gmail.com|grouping sets|status=WIP|Pavel Stehule}}<br />
<br />
{{patch|6EEA43D22289484890D119821101B1DF2C1683@exchange20.mercury.ad.ubc.ca|Improve Performance of Multi-Batch Hash Join for Skewed Data Sets|Ramon Lawrence/Bryce Cutt}}<br />
<br />
{{patch|48FC7E84.3080702@hagander.net|SSL cleanups/hostname verification|Magnus Hagander}}<br />
<br />
{{patch|49009D67.4040202@hagander.net|clientcert option for pg_hba|Magnus Hagander}}<br />
<br />
{{patch|e4ccc24e0810222010p12bae2f4xa3a11cb2bc51bd89@mail.gmail.com|pg_standby support for compressed segments|Charles Duffy}}<br />
<br />
{{patch|162867790810260428p56d16352qa1ec5c4c5330f25c@mail.gmail.com|default values for function's parameters|Pavel Stehule}}<br />
{{comment|Pavel Stehule| fix known bugs, currently only doc should be finished}}<br />
<br />
{{patch|490394B7.6090503@lelarge.info|ALTER DATABASE WITH TABLESPACE Statement|Guillaume Lelarge}}<br />
<br />
{{patch|Pine.BSO.4.64.0810271955030.28764@leary.csoft.net|use new heap_(form/deform/modify)_tuple API|Kris Jurka|reviewers=Zdenek Kotala|status=Ready for commit}}<br />
{{comment|Zdenek Kotala| It seems OK. Needs apply also {{messageLink|Pine.BSO.4.64.0810281721500.6833@leary.csoft.net|pfree patch.}}}}<br />
<br />
{{patch|49076F39.1080502@hagander.net|regexp support in usermaps|Magnus Hagander}}<br />
<br />
{{patch|Pine.BSO.4.64.0810281622240.9851@leary.csoft.net|don't use MAKE_PTR/OFFSET for shmem pointers|Kris Jurka}}<br />
<br />
{{patch|603c8f070810282045g7fa6bdf9p53f03114d49643d7@mail.gmail.com|bulk inserts - keep most recent page pinned|Robert Haas}}<br />
{{comment|Robert Haas|based on work by Simon Riggs: [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01080.php original idea],[http://archives.postgresql.org/pgsql-patches/2008-02/msg00140.php original patch], [http://archives.postgresql.org/pgsql-patches/2008-02/msg00154.php Tom Lane's comments]}}<br />
{{comment|Robert Haas|Tom's comments on my [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01276.php design proposal] are {{messageLink|17996.1225049097@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|49086E4C.9030602@sun.com|htup and bufpage API clean up|Zdenek Kotala}}<br />
{{comment|Zdenek Kotala|New version is {{messageLink|490875FA.4020709@sun.com|here}}}}<br />
<br />
{{patch|49097338.2070700@gmail.com|SQL/MED compatible connection manager|Martin Pihlak|status=WIP}}<br />
{{comment|Martin Pihlak|Updated patch {{messageLink|490B28FA.4080101@gmail.com|here}}}}<br />
<br />
{{patch|20081029164000.GL27466@fetter.org|pre-MED|David Fetter}}<br />
<br />
{{patch|4905AE17.7090305@enterprisedb.com|Visibility map, partial vacuums|status=WIP|Heikki Linnakangas}}<br />
<br />
{{patch|49085327.5010608@enterprisedb.com|Updating FSM on recovery|Heikki Linnakangas}}<br />
<br />
{{patch|1225010283.21241.33.camel@localhost.localdomain|new correlation metric|Jeff Davis}}<br />
<br />
{{patch|20081029183248.GE4331@alvh.no-ip.org|Block-level CRC checks|Alvaro Herrera|status=WIP}}<br />
<br />
{{patch|4909DFCE.1000702@sun.com|HeapTuple version extension + code cleanup|Zdenek Kotala}}<br />
<br />
{{patch|4909B326.507@enterprisedb.com|Optimizing COPY with memchr()|Heikki Linnakangas}}<br />
<br />
{{patch|87ljw5c0lx.fsf@oxford.xeocode.com|posix_fadvise|Gregory Stark}}<br />
<br />
{{patch|4909726F.8000800@gmx.net|TABLE command|Peter Eisentraut}}<br />
<br />
{{patch|200810271936.m9RJaGW09544@momjian.us|libpq callback unregistration|Bruce Momjian}}<br />
<br />
{{patch|f205bb120810280833x340324d3m19a4f8aa65d822b@mail.gmail.com|FAQ_Solaris 1.28 to spanish|Emanuel CALVO FRANCO}}<br />
<br />
{{patch|3f0b79eb0810310436w360f0afdy76ff1499b177ce0d@mail.gmail.com|Synchronous log-shipping replication|Masao Fujii|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|490B07BA.6030109@sigaev.ru|GIN fast insert|Teodor Sigaev, Oleg Bartunov}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Committed patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|20080803.114711.73374027.t-ishii@sraoss.co.jp|Common Table Expressions|Yoshiyuki Asaba|status=Committed 2008-10-04|reviewers=Jeff Davis}}<br />
{{comment|David Fetter|README is {{messageLink|20080818.163852.105172778.t-ishii@sraoss.co.jp|here.}}}}<br />
{{comment|David Fetter|Git repository is [http://git.postgresql.org/git/~davidfetter/cte/.git here.]}}<br />
{{comment|David Fetter|[[CTEReadme]]}}<br />
{{comment|David Fetter|[[CTESQLStandard| Fair Use from the draft SQL:2008 standard (WIP)]]}}<br />
{{review|13449.1221589943@sss.pgh.pa.us|tgl|needs a good bit of work yet}}<br />
<br />
{{patch|Pine.GSO.4.64.0809152349440.19910@westnet.com|Add default_val to pg_settings|status=Committed 2008-10-06|Greg Smith|reviewers=Simon Riggs,Magnus Hagander}}<br />
<br />
{{patch|20081016102603.897D.52131E4D@oss.ntt.co.jp|Noisy _dosmaperror|status=Committed 2008-10-16|Takahiro Itagaki|reviewers=Tom Lane}}<br />
<br />
{{patch|b4e5ce320810151918g2acf69ebh9f80f4f2e1c203a0@mail.gmail.com|Memory leak on hashed agg rescan|status=Committed 2008-10-16|Neil Conway|reviewers=Tom Lane}}<br />
{{review|10455.1224160007@sss.pgh.pa.us|Tom Lane|move some logic to separate function}}<br />
<br />
{{patch|1223383838.4747.154.camel@ebony.2ndQuadrant|Atomic subtransaction commit|status=Committed 2008-10-20|Simon Riggs|reviewers=Alvaro Herrera}} <br />
<br />
{{patch|3327.1224535092@sss.pgh.pa.us|add placeholder variables to planner|status=Committed 2008-10-22|Tom Lane}}<br />
<br />
{{patch|48E271C5.7010907@hagander.net|pg_hba options parsing|status=Committed 2008-10-23|Magnus Hagander|reviewers=Bruce Momjian}}<br />
{{comment|Robert Haas|{{messageLink|48F0DE8B.8030004@hagander.net|updated patch}}}}<br />
<br />
{{patch|48FC3994.8040809@hagander.net|libpq ssl -> clear fallback looses error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905D22D.9040001@hagander.net|better hba parsing error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905A1DE.5030102@hagander.net|remove crypt authentication|status=Committed 2008-10-28|Magnus Hagander}}<br />
<br />
{{patch|4905F515.3020208@gmx.net|Unicode escapes in literals|status=Committed 2008-10-29|Peter Eisentraut}}<br />
<br />
{{patch|490A138E.80100@enterprisedb.com|User defined I/O conversion casts|status=Committed 2008-10-31|Heikki Linnakangas}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Returned with Feedback ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{CommitFestEndSection}}</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-11&diff=3163CommitFest 2008-112008-10-31T16:00:25Z<p>Martin.pihlak: </p>
<hr />
<div>__TOC__<br />
<br />
This is the page for the CommitFest starting '''2008 November'''.<br />
<br />
{{CommitFestOpen}}<br />
<br />
== Pending patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei|reviewers=Peter Eisentraut, Abhijit Menon-Sen}}<br />
{{comment|Peter|checking with Solaris engineers about compatibility with Solaris TX; will continue review throughout August}}<br />
{{comment|KaiGai|{{messageLink|488F0C02.4020708@ak.jp.nec.com|latest patch versions}}}}<br />
{{comment|KaiGai|{{messageLink|48BA12F4.1090201@kaigai.gr.jp|latest patch versions}}}}<br />
{{comment|Robert Haas|KaiGai's latest version is {{messageLink|48F46606.4080207@ak.jp.nec.com|r1120}}}}<br />
{{comment|Robert Haas|{{messageLink|48F71E36.9010203@ak.jp.nec.com|latest version}}, now with 6 patches}}<br />
{{comment|KaiGai|[[SEPostgreSQL]] can be a comprehensive documentation (now in progress)}}<br />
{{comment|KaiGai|{{messageLink|490AD10A.6020902@ak.jp.nec.com|latest patches (r1168)}}}}<br />
<br />
<br />
{{patch|1220213074.4371.173.camel@ebony.2ndQuadrant|Infrastructure changes for recovery|status=Pending Review|Simon Riggs|reviewers=Tom Lane, Heikki Linnakangas}} <br />
{{comment|sriggs| important patch for other work}}<br />
{{comment|tgl|some comments {{messageLink|1905.1220895241@sss.pgh.pa.us|here}}}}<br />
{{comment|tgl|updated patch {{messageLink|1221080797.3913.768.camel@ebony.2ndQuadrant|here}}, still being tested}}<br />
{{comment|tgl|Simon found {{messageLink|1221725145.3913.2315.camel@ebony.2ndQuadrant|some issues}}}}<br />
{{comment|tgl|{{messageLink|1222184541.4445.400.camel@ebony.2ndQuadrant|patch v7}} here}}<br />
{{comment|tgl|it's still got {{messageLink|28973.1222381719@sss.pgh.pa.us|issues}}}}<br />
{{comment|Robert Haas|{{messageLink|1222815151.4445.1397.camel@ebony.2ndQuadrant|patch v8}} here}}<br />
{{comment|Robert Haas|{{messageLink|1223472898.4747.310.camel@ebony.2ndQuadrant|patch v9}} here, in response to {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's review}}}}<br />
<br />
{{patch|1220174867.4371.107.camel@ebony.2ndQuadrant|rmgr hooks and contrib/rmgr_hook|status=Waiting on author|Simon Riggs}} <br />
{{comment|sriggs| deferrable, if required}}<br />
{{comment|tgl|I think the plan is for this to wait till "infrastructure" patch goes in}}<br />
<br />
{{patch|37ed240d0809030015u73b65b66v70fd76741317c6f5@mail.gmail.com|pg_typeof()|Brendan Jurd}}<br />
<br />
{{patch|48C181D4.8030807@gmail.com|reducing statistics write overhead|Martin Pihlak}}<br />
{{comment|Martin Pihlak|Latest patch {{messageLink|48C594D8.6050504@gmail.com|here}}}}<br />
<br />
{{patch|BLU110-W38CE0A22D467A8C3D9736CFF540@phx.gbl|Support PLUGINS lines in Makefiles, similar to MODULES|Asif Naeem}}<br />
{{comment|Dave Page|This doesn't work with the edb-debugger plugin, which is the only such plugin around AFAIK. It needs to ignore comments on the PLUGINS line, and handle multiple targets (plugin_debugger, pldbgapi, targetinfo etc). Not sure if we want that complexity though.}}<br />
{{comment|Heikki|Unix-makefile version: {{messageLink|BLU110-W57823CEB7DC113354471EFF3B0@phx.gbl|here}}}}<br />
<br />
<br />
{{patch|48D15471.6080305@cheapcomplexdevices.com|SQL Standard Interval output and IntervalStyle GUC|Ron Mayer}}<br />
{{comment|Ron Mayer|<br />
An update {{messageLink|48D52E48.406@cheapcomplexdevices.com|here}} fixed <br />
some bugs in GUC setting. <br />
Another update {{messageLink|48E49BDC.4090402@cheapcomplexdevices.com|here}}, <br />
brought up-to-date with HEAD}}<br />
{{comment|Ron Mayer|Brought up-to-date with head [http://0ape.com/postgres_interval_patches/ here]. Now allows setting IntervalStyle through an environment variable because pg_regress had set interval styles (as a side-effect of setting DateStyles) through the environment, some minor cleanup.}}<br />
<br />
{{patch|48E4A30C.3000503@cheapcomplexdevices.com|ISO 8601 interval literal input and output|Ron Mayer}}<br />
{{comment|Ron Mayer|Note that this patch doesn't apply directly to HEAD, but depends on the {{messageLink|48E49BDC.4090402@cheapcomplexdevices.com|IntervalStyle GUC patch}} to be applied first.}}<br />
{{comment|Ron Mayer|The initial (2003) version of this patch along with a thread which explains the feature a bit more can be found [http://archives.postgresql.org/pgsql-patches/2003-09/msg00103.php here].}}<br />
{{comment|Ron Mayer|An update [http://0ape.com/postgres_interval_patches/ here]. Cleaned up code and added regression tests.}}<br />
<br />
{{patch|48CEDE68.7090501@cheapcomplexdevices.com|Interval rounding consistency|Ron Mayer}}<br />
{{comment|Ron Mayer|Patch 3 [http://0ape.com/postgres_interval_patches/ here] refactors the interval code to remove much of the copy&paste in DecodeInterval and EncodeInterval with the side effect of making interval rounding more consistent between styles. This patch applies on top of the IntervalStyle patch and the ISO 8601 Interval patch.}}<br />
<br />
<br />
{{patch|03c301c91737$be5a2a30$0e01a8c0@IBMC9A0F63B40D|Solve a problem of LC_TIME of windows|Hiroshi Saito}}<br />
<br />
{{patch|20080901063855.GJ16005@tamriel.snowman.net|Column-level Permissions|Stephen Frost|status=WIP|reviewers=Markus Wanner}}<br />
{{comment|Stephen Frost|Updated patch {{messageLink|20080902221823.GL16005@tamriel.snowman.net|here}}}}<br />
{{review|48DB48AC.5010400@bluegap.ch|Markus Wanner|Awaiting updated patch.}}<br />
<br />
{{patch|0BD2E4E9-AF5A-4B4F-B546-027424EE8FAD@kineticode.com|Tests citext casts|David Wheeler}}<br />
<br />
{{patch|48E22CF5.4050503@sun.com|PageGetTempPage cleanup |Zdenek Kotala}}<br />
{{comment|Zdenek Kotala|Original discussion {{messageLink|4938.1217862947@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|603c8f070808070503jd7be083kcce3e16345affb08@mail.gmail.com|add columns via CREATE OR REPLACE VIEW|Robert Haas}}<br />
{{comment|Robert Haas|some further justification of the proposed design {{messageLink|603c8f070808070956t1ab98dcdr933575eb096e4c28@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|questions about how to move forward {{messageLink|603c8f070810031839y7ce9a852o86effbab9fd6dd9b@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|a {{messageLink|482096EC.3000805@dunslane.net|similar feature request}} from Andrew Dunstan}}<br />
<br />
{{patch|1223379173.4747.145.camel@ebony.2ndQuadrant|Reducing some DDL Locks to ShareLock|status=Pending Review|Simon Riggs}} <br />
{{comment|Robert Haas|{{messageLink|1722552592.7.1224882093461.JavaMail.root@spotone|ddl_lock_reduce.v4.patch}}}}<br />
<br />
{{patch|Pine.BSO.4.64.0810081931240.11647@leary.csoft.net|Fixes for psql describeOneTableDetails|Kris Jurka}}<br />
<br />
{{patch|1223472186.4747.301.camel@ebony.2ndQuadrant|pg_stop_backup wait bug fix|Simon Riggs}}<br />
{{comment|Robert Haas|sriggs extracted this from recovery infrastructure patch per {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's suggestion}}}}<br />
<br />
{{patch|20081009165157.9BE4.52131E4D@oss.ntt.co.jp|contrib/auto_explain|Takahiro Itagaki|}}<br />
<br />
{{patch|603c8f070810092009s1312d30bxc854cdfb5d9fed7e@mail.gmail.com|Allow the UUID type to accept non-standard formats|Robert Haas}}<br />
<br />
{{patch|603c8f070810101937n776c1e7cvd6a12345b0bbda28@mail.gmail.com|array_ndims|Robert Haas}}<br />
<br />
{{patch|48F04B7C.3080303@benedekl.tvnetwork.hu|pg_dump roles support|Benedek Laszlo}}<br />
<br />
{{patch|20081011172450.3402.52131E4D@oss.ntt.co.jp|contrib/pg_stat_statements|Takahiro Itagaki}}<br />
{{comment|Itagaki|{{messageLink|20081027171917.ADD6.52131E4D@oss.ntt.co.jp|latest patch versions}}}}<br />
<br />
{{patch|49078031.9030002@gmail.com|contrib/pg_stat_staments querydesc|Martin Pihlak}}<br />
{{comment|Martin Pihlak|Updated patch {{messageLink|490A00A8.7050708@gmail.com|here}}}}<br />
<br />
<br />
{{patch|c2ee6dbd0810100553gd328275ue2eb6e14bee70a8@mail.gmail.com|adding VERBOSE option to CLUSTER|Jim Cox}}<br />
<br />
{{patch|e08cc0400810270912u49a6ec83vc23984c01f368f76@mail.gmail.com|Window Functions|Hitoshi Harada|reviewers=Heikki Linnakangas}}<br />
{{comment|Harada|updated patch is {{messageLink|e08cc0400810310721l22a6bb7kb6a300ce66443806@mail.gmail.com|here}}}}<br />
<br />
{{patch|48F1FC7E.1060406@sun.com|Extending pg_class info + more flexible TOAST chunk size|Zdenek Kotala}}<br />
<br />
{{patch|48EFA13C.2060407@frogthinker.org|Transactions and temp tables|Emmanuel Cecchet|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|20952F54-6730-49D8-99A3-1834697790B5@decibel.org|array_length|Jim C. Nasby}}<br />
<br />
{{patch|603c8f070810151933p445978b3td481a5422a2aebf4@mail.gmail.com|array_agg|Robert Haas}}<br />
{{comment|Robert Haas|{{messageLink|27bbfebe0810151633q1aac3ea8v864bea997f3cc5ec@mail.gmail.com|another version}} from Ian Caulfield and {{messageLink|1225045937.4434.21.camel@localhost.localdomain|yet another}} from Jeff Davis}}<br />
<br />
{{patch|490878AC.1@dunslane.net|parallel restore|status=WIP|Andrew Dunstan}}<br />
<br />
{{patch|48F53EC0.3020004@timbira.com|autovacuum and reloption|status=WIP|Euler Taveira de Oliveira|reviewers=Alvaro Herrera}}<br />
<br />
{{patch|162867790810170316l4eeecb0bq321dd771f8f4e661@mail.gmail.com|grouping sets|status=WIP|Pavel Stehule}}<br />
<br />
{{patch|6EEA43D22289484890D119821101B1DF2C1683@exchange20.mercury.ad.ubc.ca|Improve Performance of Multi-Batch Hash Join for Skewed Data Sets|Ramon Lawrence/Bryce Cutt}}<br />
<br />
{{patch|48FC7E84.3080702@hagander.net|SSL cleanups/hostname verification|Magnus Hagander}}<br />
<br />
{{patch|49009D67.4040202@hagander.net|clientcert option for pg_hba|Magnus Hagander}}<br />
<br />
{{patch|e4ccc24e0810222010p12bae2f4xa3a11cb2bc51bd89@mail.gmail.com|pg_standby support for compressed segments|Charles Duffy}}<br />
<br />
{{patch|162867790810260428p56d16352qa1ec5c4c5330f25c@mail.gmail.com|default values for function's parameters|Pavel Stehule}}<br />
{{comment|Pavel Stehule| fix known bugs, currently only doc should be finished}}<br />
<br />
{{patch|490394B7.6090503@lelarge.info|ALTER DATABASE WITH TABLESPACE Statement|Guillaume Lelarge}}<br />
<br />
{{patch|Pine.BSO.4.64.0810271955030.28764@leary.csoft.net|use new heap_(form/deform/modify)_tuple API|Kris Jurka|reviewers=Zdenek Kotala|status=Ready for commit}}<br />
{{comment|Zdenek Kotala| It seems OK. Needs apply also {{messageLink|Pine.BSO.4.64.0810281721500.6833@leary.csoft.net|pfree patch.}}}}<br />
<br />
{{patch|49076F39.1080502@hagander.net|regexp support in usermaps|Magnus Hagander}}<br />
<br />
{{patch|Pine.BSO.4.64.0810281622240.9851@leary.csoft.net|don't use MAKE_PTR/OFFSET for shmem pointers|Kris Jurka}}<br />
<br />
{{patch|603c8f070810282045g7fa6bdf9p53f03114d49643d7@mail.gmail.com|bulk inserts - keep most recent page pinned|Robert Haas}}<br />
{{comment|Robert Haas|based on work by Simon Riggs: [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01080.php original idea],[http://archives.postgresql.org/pgsql-patches/2008-02/msg00140.php original patch], [http://archives.postgresql.org/pgsql-patches/2008-02/msg00154.php Tom Lane's comments]}}<br />
{{comment|Robert Haas|Tom's comments on my [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01276.php design proposal] are {{messageLink|17996.1225049097@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|49086E4C.9030602@sun.com|htup and bufpage API clean up|Zdenek Kotala}}<br />
{{comment|Zdenek Kotala|New version is {{messageLink|490875FA.4020709@sun.com|here}}}}<br />
<br />
{{patch|49097338.2070700@gmail.com|SQL/MED compatible connection manager|Martin Pihlak|status=WIP}}<br />
<br />
{{patch|20081029164000.GL27466@fetter.org|pre-MED|David Fetter}}<br />
<br />
{{patch|4905AE17.7090305@enterprisedb.com|Visibility map, partial vacuums|status=WIP|Heikki Linnakangas}}<br />
<br />
{{patch|49085327.5010608@enterprisedb.com|Updating FSM on recovery|Heikki Linnakangas}}<br />
<br />
{{patch|1225010283.21241.33.camel@localhost.localdomain|new correlation metric|Jeff Davis}}<br />
<br />
{{patch|20081029183248.GE4331@alvh.no-ip.org|Block-level CRC checks|Alvaro Herrera|status=WIP}}<br />
<br />
{{patch|4909DFCE.1000702@sun.com|HeapTuple version extension + code cleanup|Zdenek Kotala}}<br />
<br />
{{patch|4909B326.507@enterprisedb.com|Optimizing COPY with memchr()|Heikki Linnakangas}}<br />
<br />
{{patch|87ljw5c0lx.fsf@oxford.xeocode.com|posix_fadvise|Gregory Stark}}<br />
<br />
{{patch|4909726F.8000800@gmx.net|TABLE command|Peter Eisentraut}}<br />
<br />
{{patch|200810271936.m9RJaGW09544@momjian.us|libpq callback unregistration|Bruce Momjian}}<br />
<br />
{{patch|f205bb120810280833x340324d3m19a4f8aa65d822b@mail.gmail.com|FAQ_Solaris 1.28 to spanish|Emanuel CALVO FRANCO}}<br />
<br />
{{patch|3f0b79eb0810310436w360f0afdy76ff1499b177ce0d@mail.gmail.com|Synchronous log-shipping replication|Masao Fujii|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|490B07BA.6030109@sigaev.ru|GIN fast insert|Teodor Sigaev, Oleg Bartunov}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Committed patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|20080803.114711.73374027.t-ishii@sraoss.co.jp|Common Table Expressions|Yoshiyuki Asaba|status=Committed 2008-10-04|reviewers=Jeff Davis}}<br />
{{comment|David Fetter|README is {{messageLink|20080818.163852.105172778.t-ishii@sraoss.co.jp|here.}}}}<br />
{{comment|David Fetter|Git repository is [http://git.postgresql.org/git/~davidfetter/cte/.git here.]}}<br />
{{comment|David Fetter|[[CTEReadme]]}}<br />
{{comment|David Fetter|[[CTESQLStandard| Fair Use from the draft SQL:2008 standard (WIP)]]}}<br />
{{review|13449.1221589943@sss.pgh.pa.us|tgl|needs a good bit of work yet}}<br />
<br />
{{patch|Pine.GSO.4.64.0809152349440.19910@westnet.com|Add default_val to pg_settings|status=Committed 2008-10-06|Greg Smith|reviewers=Simon Riggs,Magnus Hagander}}<br />
<br />
{{patch|20081016102603.897D.52131E4D@oss.ntt.co.jp|Noisy _dosmaperror|status=Committed 2008-10-16|Takahiro Itagaki|reviewers=Tom Lane}}<br />
<br />
{{patch|b4e5ce320810151918g2acf69ebh9f80f4f2e1c203a0@mail.gmail.com|Memory leak on hashed agg rescan|status=Committed 2008-10-16|Neil Conway|reviewers=Tom Lane}}<br />
{{review|10455.1224160007@sss.pgh.pa.us|Tom Lane|move some logic to separate function}}<br />
<br />
{{patch|1223383838.4747.154.camel@ebony.2ndQuadrant|Atomic subtransaction commit|status=Committed 2008-10-20|Simon Riggs|reviewers=Alvaro Herrera}} <br />
<br />
{{patch|3327.1224535092@sss.pgh.pa.us|add placeholder variables to planner|status=Committed 2008-10-22|Tom Lane}}<br />
<br />
{{patch|48E271C5.7010907@hagander.net|pg_hba options parsing|status=Committed 2008-10-23|Magnus Hagander|reviewers=Bruce Momjian}}<br />
{{comment|Robert Haas|{{messageLink|48F0DE8B.8030004@hagander.net|updated patch}}}}<br />
<br />
{{patch|48FC3994.8040809@hagander.net|libpq ssl -> clear fallback looses error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905D22D.9040001@hagander.net|better hba parsing error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905A1DE.5030102@hagander.net|remove crypt authentication|status=Committed 2008-10-28|Magnus Hagander}}<br />
<br />
{{patch|4905F515.3020208@gmx.net|Unicode escapes in literals|status=Committed 2008-10-29|Peter Eisentraut}}<br />
<br />
{{patch|490A138E.80100@enterprisedb.com|User defined I/O conversion casts|status=Committed 2008-10-31|Heikki Linnakangas}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Returned with Feedback ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{CommitFestEndSection}}</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3162SqlMedConnectionManager2008-10-31T15:29:40Z<p>Martin.pihlak: /* Links */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01319.php and more ...]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3161SqlMedConnectionManager2008-10-31T15:28:24Z<p>Martin.pihlak: /* Issues */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* Some ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3160SqlMedConnectionManager2008-10-31T15:26:50Z<p>Martin.pihlak: /* Connection manager C API */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
<br />
; GetForeignServer(serverid) : Look up the foreign server definition.<br />
<pre><br />
ForeignServer *GetForeignServer(Oid serverid);<br />
</pre><br />
<br />
; GetForeignUserMapping(userid,serverid) : Look up remote mapping for the local user.<br />
<pre><br />
ForeignUserMapping *GetForeignUserMapping(Oid userid, Oid serverid);<br />
</pre><br />
<br />
; GetForeignDataWrapper(fdwid) : Look up foreign data wrapper.<br />
<pre><br />
ForeignDataWrapper *GetForeignDataWrapper(Oid fdwid);<br />
</pre><br />
<br />
; GetForeignDataWrapperInterface(fdw) : Fetch the FDW interface from cache. Load the external functions.<br />
<pre><br />
ForeignDataWrapperInterface *GetForeignDataWrapperInterface(ForeignDataWrapper *fdw);<br />
</pre><br />
<br />
; GetRemoteConnectionInfo(serverid,userid) : Combines all of the above to obtain connection details.<br />
<pre><br />
List *GetRemoteConnectionInfo(Oid serverid, Oid userid);<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3159SqlMedConnectionManager2008-10-31T15:19:22Z<p>Martin.pihlak: /* Foreign data wrapper API */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; GetConnectionInfo(fdw, server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *<br />
GetConnectionInfo(ForeignDataWrapper *fdw, ForeignServer *server,<br />
ForeignUserMapping *um)<br />
</pre><br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
Minimally we need:<br />
<br />
; connection lookup(name) : lookup server, FDW and user mapping. Call FDW for connection details.<br />
<br />
Additional functions maybe required for obtaining details about servers, user mappings and FDW:<br />
; server lookup(name) : Server details: TYPE, VERSION etc.<br />
<pre><br />
ForeignServer *<br />
get_foreign_server(Oid serverid)<br />
</pre><br />
<br />
; user mapping lookup(server) : User mapping details for the session user.<br />
<pre><br />
ForeignUserMapping *<br />
get_foreign_user_mapping(Oid userid, Oid serverid)<br />
</pre><br />
<br />
; foreign data wrapper lookup(name) : Foreign data wrapper details.<br />
<pre><br />
ForeignDataWrapper *<br />
get_foreign_data_wrapper(Oid fdwid)<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3152SqlMedConnectionManager2008-10-31T12:20:59Z<p>Martin.pihlak: /* Connection manager C API */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *GetConnectionInfo(ForeignServer *server, ForeignUserMapping *um)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
Minimally we need:<br />
<br />
; connection lookup(name) : lookup server, FDW and user mapping. Call FDW for connection details.<br />
<br />
Additional functions maybe required for obtaining details about servers, user mappings and FDW:<br />
; server lookup(name) : Server details: TYPE, VERSION etc.<br />
<pre><br />
ForeignServer *<br />
get_foreign_server(Oid serverid)<br />
</pre><br />
<br />
; user mapping lookup(server) : User mapping details for the session user.<br />
<pre><br />
ForeignUserMapping *<br />
get_foreign_user_mapping(Oid userid, Oid serverid)<br />
</pre><br />
<br />
; foreign data wrapper lookup(name) : Foreign data wrapper details.<br />
<pre><br />
ForeignDataWrapper *<br />
get_foreign_data_wrapper(Oid fdwid)<br />
</pre><br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3151SqlMedConnectionManager2008-10-31T12:19:23Z<p>Martin.pihlak: /* Foreign data wrapper API */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
<pre><br />
List *GetConnectionInfo(ForeignServer *server, ForeignUserMapping *um)<br />
</pre><br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
Minimally we need:<br />
<br />
; connection lookup(name) : lookup server, FDW and user mapping. Call FDW for connection details.<br />
<br />
Additional functions maybe required for obtaining details about servers, user mappings and FDW:<br />
; server lookup(name) : Server details: TYPE, VERSION etc.<br />
<br />
; user mapping lookup(server) : User mapping details for the session user.<br />
<br />
; foreign data wrapper lookup(name) : Foreign data wrapper details.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=CommitFest_2008-11&diff=3148CommitFest 2008-112008-10-31T08:15:38Z<p>Martin.pihlak: </p>
<hr />
<div>__TOC__<br />
<br />
This is the page for the CommitFest starting '''2008 November'''.<br />
<br />
{{CommitFestOpen}}<br />
<br />
== Pending patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|4863B3DA.8030209@kaigai.gr.jp|SE-PostgreSQL patches|Kaigai Kohei|reviewers=Peter Eisentraut, Abhijit Menon-Sen}}<br />
{{comment|Peter|checking with Solaris engineers about compatibility with Solaris TX; will continue review throughout August}}<br />
{{comment|KaiGai|{{messageLink|488F0C02.4020708@ak.jp.nec.com|latest patch versions}}}}<br />
{{comment|KaiGai|{{messageLink|48BA12F4.1090201@kaigai.gr.jp|latest patch versions}}}}<br />
{{comment|Robert Haas|KaiGai's latest version is {{messageLink|48F46606.4080207@ak.jp.nec.com|r1120}}}}<br />
{{comment|Robert Haas|{{messageLink|48F71E36.9010203@ak.jp.nec.com|latest version}}, now with 6 patches}}<br />
{{comment|KaiGai|[[SEPostgreSQL]] can be a comprehensive documentation (now in progress)}}<br />
{{comment|KaiGai|{{messageLink|49082203.1090302@ak.jp.nec.com|latest patches (r1155)}}}}<br />
<br />
{{patch|1220213074.4371.173.camel@ebony.2ndQuadrant|Infrastructure changes for recovery|status=Pending Review|Simon Riggs|reviewers=Tom Lane, Heikki Linnakangas}} <br />
{{comment|sriggs| important patch for other work}}<br />
{{comment|tgl|some comments {{messageLink|1905.1220895241@sss.pgh.pa.us|here}}}}<br />
{{comment|tgl|updated patch {{messageLink|1221080797.3913.768.camel@ebony.2ndQuadrant|here}}, still being tested}}<br />
{{comment|tgl|Simon found {{messageLink|1221725145.3913.2315.camel@ebony.2ndQuadrant|some issues}}}}<br />
{{comment|tgl|{{messageLink|1222184541.4445.400.camel@ebony.2ndQuadrant|patch v7}} here}}<br />
{{comment|tgl|it's still got {{messageLink|28973.1222381719@sss.pgh.pa.us|issues}}}}<br />
{{comment|Robert Haas|{{messageLink|1222815151.4445.1397.camel@ebony.2ndQuadrant|patch v8}} here}}<br />
{{comment|Robert Haas|{{messageLink|1223472898.4747.310.camel@ebony.2ndQuadrant|patch v9}} here, in response to {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's review}}}}<br />
<br />
{{patch|1220174867.4371.107.camel@ebony.2ndQuadrant|rmgr hooks and contrib/rmgr_hook|status=Waiting on author|Simon Riggs}} <br />
{{comment|sriggs| deferrable, if required}}<br />
{{comment|tgl|I think the plan is for this to wait till "infrastructure" patch goes in}}<br />
<br />
{{patch|37ed240d0809030015u73b65b66v70fd76741317c6f5@mail.gmail.com|pg_typeof()|Brendan Jurd}}<br />
<br />
{{patch|48C181D4.8030807@gmail.com|reducing statistics write overhead|Martin Pihlak}}<br />
{{comment|Martin Pihlak|Latest patch {{messageLink|48C594D8.6050504@gmail.com|here}}}}<br />
<br />
{{patch|BLU110-W38CE0A22D467A8C3D9736CFF540@phx.gbl|Support PLUGINS lines in Makefiles, similar to MODULES|Asif Naeem}}<br />
{{comment|Dave Page|This doesn't work with the edb-debugger plugin, which is the only such plugin around AFAIK. It needs to ignore comments on the PLUGINS line, and handle multiple targets (plugin_debugger, pldbgapi, targetinfo etc). Not sure if we want that complexity though.}}<br />
{{comment|Heikki|Unix-makefile version: {{messageLink|BLU110-W57823CEB7DC113354471EFF3B0@phx.gbl|here}}}}<br />
<br />
<br />
{{patch|48D15471.6080305@cheapcomplexdevices.com|SQL Standard Interval output and IntervalStyle GUC|Ron Mayer}}<br />
{{comment|Ron Mayer|<br />
An update {{messageLink|48D52E48.406@cheapcomplexdevices.com|here}} fixed <br />
some bugs in GUC setting. <br />
Another update {{messageLink|48E49BDC.4090402@cheapcomplexdevices.com|here}}, <br />
brought up-to-date with HEAD}}<br />
{{comment|Ron Mayer|Brought up-to-date with head [http://0ape.com/postgres_interval_patches/ here]. Now allows setting IntervalStyle through an environment variable because pg_regress had set interval styles (as a side-effect of setting DateStyles) through the environment, some minor cleanup.}}<br />
<br />
{{patch|48E4A30C.3000503@cheapcomplexdevices.com|ISO 8601 interval literal input and output|Ron Mayer}}<br />
{{comment|Ron Mayer|Note that this patch doesn't apply directly to HEAD, but depends on the {{messageLink|48E49BDC.4090402@cheapcomplexdevices.com|IntervalStyle GUC patch}} to be applied first.}}<br />
{{comment|Ron Mayer|The initial (2003) version of this patch along with a thread which explains the feature a bit more can be found [http://archives.postgresql.org/pgsql-patches/2003-09/msg00103.php here].}}<br />
{{comment|Ron Mayer|An update [http://0ape.com/postgres_interval_patches/ here]. Cleaned up code and added regression tests.}}<br />
<br />
{{patch|48CEDE68.7090501@cheapcomplexdevices.com|Interval rounding consistency|Ron Mayer}}<br />
{{comment|Ron Mayer|Patch 3 [http://0ape.com/postgres_interval_patches/ here] refactors the interval code to remove much of the copy&paste in DecodeInterval and EncodeInterval with the side effect of making interval rounding more consistent between styles. This patch applies on top of the IntervalStyle patch and the ISO 8601 Interval patch.}}<br />
<br />
<br />
{{patch|03c301c91737$be5a2a30$0e01a8c0@IBMC9A0F63B40D|Solve a problem of LC_TIME of windows|Hiroshi Saito}}<br />
<br />
{{patch|20080901063855.GJ16005@tamriel.snowman.net|Column-level Permissions|Stephen Frost|status=WIP|reviewers=Markus Wanner}}<br />
{{comment|Stephen Frost|Updated patch {{messageLink|20080902221823.GL16005@tamriel.snowman.net|here}}}}<br />
{{review|48DB48AC.5010400@bluegap.ch|Markus Wanner|Awaiting updated patch.}}<br />
<br />
{{patch|0BD2E4E9-AF5A-4B4F-B546-027424EE8FAD@kineticode.com|Tests citext casts|David Wheeler}}<br />
<br />
{{patch|48E22CF5.4050503@sun.com|PageGetTempPage cleanup |Zdenek Kotala}}<br />
{{comment|Zdenek Kotala|Original discussion {{messageLink|4938.1217862947@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|603c8f070808070503jd7be083kcce3e16345affb08@mail.gmail.com|add columns via CREATE OR REPLACE VIEW|Robert Haas}}<br />
{{comment|Robert Haas|some further justification of the proposed design {{messageLink|603c8f070808070956t1ab98dcdr933575eb096e4c28@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|questions about how to move forward {{messageLink|603c8f070810031839y7ce9a852o86effbab9fd6dd9b@mail.gmail.com|here}}}}<br />
{{comment|Robert Haas|a {{messageLink|482096EC.3000805@dunslane.net|similar feature request}} from Andrew Dunstan}}<br />
<br />
{{patch|1223379173.4747.145.camel@ebony.2ndQuadrant|Reducing some DDL Locks to ShareLock|status=Pending Review|Simon Riggs}} <br />
{{comment|Robert Haas|{{messageLink|1722552592.7.1224882093461.JavaMail.root@spotone|ddl_lock_reduce.v4.patch}}}}<br />
<br />
{{patch|Pine.BSO.4.64.0810081931240.11647@leary.csoft.net|Fixes for psql describeOneTableDetails|Kris Jurka}}<br />
<br />
{{patch|1223472186.4747.301.camel@ebony.2ndQuadrant|pg_stop_backup wait bug fix|Simon Riggs}}<br />
{{comment|Robert Haas|sriggs extracted this from recovery infrastructure patch per {{messageLink|48EC9CC5.6060803@enterprisedb.com|Heikki's suggestion}}}}<br />
<br />
{{patch|20081009165157.9BE4.52131E4D@oss.ntt.co.jp|contrib/auto_explain|Takahiro Itagaki|}}<br />
<br />
{{patch|603c8f070810092009s1312d30bxc854cdfb5d9fed7e@mail.gmail.com|Allow the UUID type to accept non-standard formats|Robert Haas}}<br />
<br />
{{patch|603c8f070810101937n776c1e7cvd6a12345b0bbda28@mail.gmail.com|array_ndims|Robert Haas}}<br />
<br />
{{patch|48F04B7C.3080303@benedekl.tvnetwork.hu|pg_dump roles support|Benedek László}}<br />
<br />
{{patch|20081011172450.3402.52131E4D@oss.ntt.co.jp|contrib/pg_stat_statements|Takahiro Itagaki}}<br />
{{comment|Itagaki|{{messageLink|20081027171917.ADD6.52131E4D@oss.ntt.co.jp|latest patch versions}}}}<br />
<br />
{{patch|49078031.9030002@gmail.com|contrib/pg_stat_staments querydesc|Martin Pihlak}}<br />
{{comment|Martin Pihlak|Updated patch {{messageLink|490A00A8.7050708@gmail.com|here}}}}<br />
<br />
<br />
{{patch|c2ee6dbd0810100553gd328275ue2eb6e14bee70a8@mail.gmail.com|adding VERBOSE option to CLUSTER|Jim Cox}}<br />
<br />
{{patch|e08cc0400810270912u49a6ec83vc23984c01f368f76@mail.gmail.com|Window Functions|Hitoshi Harada|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|48F1FC7E.1060406@sun.com|Extending pg_class info + more flexible TOAST chunk size|Zdenek Kotala}}<br />
<br />
{{patch|48EFA13C.2060407@frogthinker.org|Transactions and temp tables|Emmanuel Cecchet|reviewers=Heikki Linnakangas}}<br />
<br />
{{patch|20952F54-6730-49D8-99A3-1834697790B5@decibel.org|array_length|Jim C. Nasby}}<br />
<br />
{{patch|603c8f070810151933p445978b3td481a5422a2aebf4@mail.gmail.com|array_agg|Robert Haas}}<br />
{{comment|Robert Haas|{{messageLink|27bbfebe0810151633q1aac3ea8v864bea997f3cc5ec@mail.gmail.com|another version}} from Ian Caulfield and {{messageLink|1225045937.4434.21.camel@localhost.localdomain|yet another}} from Jeff Davis}}<br />
<br />
{{patch|490878AC.1@dunslane.net|parallel restore|status=WIP|Andrew Dunstan}}<br />
<br />
{{patch|48F53EC0.3020004@timbira.com|autovacuum and reloption|status=WIP|Euler Taveira de Oliveira|reviewers=Alvaro Herrera}}<br />
<br />
{{patch|162867790810170316l4eeecb0bq321dd771f8f4e661@mail.gmail.com|grouping sets|status=WIP|Pavel Stehule}}<br />
<br />
{{patch|6EEA43D22289484890D119821101B1DF2C1683@exchange20.mercury.ad.ubc.ca|Improve Performance of Multi-Batch Hash Join for Skewed Data Sets|Ramon Lawrence/Bryce Cutt}}<br />
<br />
{{patch|48FC7E84.3080702@hagander.net|SSL cleanups/hostname verification|Magnus Hagander}}<br />
<br />
{{patch|49009D67.4040202@hagander.net|clientcert option for pg_hba|Magnus Hagander}}<br />
<br />
{{patch|e4ccc24e0810222010p12bae2f4xa3a11cb2bc51bd89@mail.gmail.com|pg_standby support for compressed segments|Charles Duffy}}<br />
<br />
{{patch|162867790810260428p56d16352qa1ec5c4c5330f25c@mail.gmail.com|default values for function's parameters|Pavel Stěhule}}<br />
<br />
{{patch|490394B7.6090503@lelarge.info|ALTER DATABASE WITH TABLESPACE Statement|Guillaume Lelarge}}<br />
<br />
{{patch|Pine.BSO.4.64.0810271955030.28764@leary.csoft.net|use new heap_(form/deform/modify)_tuple API|Kris Jurka|reviewers=Zdenek Kotala|status=Ready for commit}}<br />
{{comment|Zdenek Kotala| It seems OK. Needs apply also {{messageLink|Pine.BSO.4.64.0810281721500.6833@leary.csoft.net|pfree patch.}}}}<br />
<br />
{{patch|49076F39.1080502@hagander.net|regexp support in usermaps|Magnus Hagander}}<br />
<br />
{{patch|Pine.BSO.4.64.0810281622240.9851@leary.csoft.net|don't use MAKE_PTR/OFFSET for shmem pointers|Kris Jurka}}<br />
<br />
{{patch|603c8f070810282045g7fa6bdf9p53f03114d49643d7@mail.gmail.com|bulk inserts - keep most recent page pinned|Robert Haas}}<br />
{{comment|Robert Haas|based on work by Simon Riggs: [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01080.php original idea],[http://archives.postgresql.org/pgsql-patches/2008-02/msg00140.php original patch], [http://archives.postgresql.org/pgsql-patches/2008-02/msg00154.php Tom Lane's comments]}}<br />
{{comment|Robert Haas|Tom's comments on my [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01276.php design proposal] are {{messageLink|17996.1225049097@sss.pgh.pa.us|here}}}}<br />
<br />
{{patch|49086E4C.9030602@sun.com|htup and bufpage API clean up|Zdenek Kotala}}<br />
{{comment|Zdenek Kotala|New version is {{messageLink|490875FA.4020709@sun.com|here}}}}<br />
<br />
{{patch|49097338.2070700@gmail.com|SQL/MED compatible connection manager|Martin Pihlak}}<br />
<br />
{{patch|20081029164000.GL27466@fetter.org|pre-MED|David Fetter}}<br />
<br />
{{patch|4905AE17.7090305@enterprisedb.com|Visibility map, partial vacuums|status=WIP|Heikki Linnakangas}}<br />
<br />
{{patch|49085327.5010608@enterprisedb.com|Updating FSM on recovery|Heikki Linnakangas}}<br />
<br />
{{patch|1225010283.21241.33.camel@localhost.localdomain|new correlation metric|Jeff Davis}}<br />
<br />
{{patch|20081029183248.GE4331@alvh.no-ip.org|Block-level CRC checks|Alvaro Herrera|status=WIP}}<br />
<br />
{{patch|4909DFCE.1000702@sun.com|HeapTuple version extension + code cleanup|Zdenek Kotala}}<br />
<br />
{{patch|4909B326.507@enterprisedb.com|Optimizing COPY with memchr()|Heikki Linnakangas}}<br />
<br />
{{patch|490A138E.80100@enterprisedb.com|User defined I/O conversion casts|Heikki Linnakangas}}<br />
<br />
{{patch|87ljw5c0lx.fsf@oxford.xeocode.com|posix_fadvise|Gregory Stark}}<br />
<br />
{{patch|4909726F.8000800@gmx.net|TABLE command|Peter Eisentraut}}<br />
<br />
{{patch|200810271936.m9RJaGW09544@momjian.us|libpq callback unregistration|Bruce Momjian}}<br />
<br />
{{patch|f205bb120810280833x340324d3m19a4f8aa65d822b@mail.gmail.com|FAQ_Solaris 1.28 to spanish|Emanuel CALVO FRANCO}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Committed patches ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{patch|20080803.114711.73374027.t-ishii@sraoss.co.jp|Common Table Expressions|Yoshiyuki Asaba|status=Committed 2008-10-04|reviewers=Jeff Davis}}<br />
{{comment|David Fetter|README is {{messageLink|20080818.163852.105172778.t-ishii@sraoss.co.jp|here.}}}}<br />
{{comment|David Fetter|Git repository is [http://git.postgresql.org/git/~davidfetter/cte/.git here.]}}<br />
{{comment|David Fetter|[[CTEReadme]]}}<br />
{{comment|David Fetter|[[CTESQLStandard| Fair Use from the draft SQL:2008 standard (WIP)]]}}<br />
{{review|13449.1221589943@sss.pgh.pa.us|tgl|needs a good bit of work yet}}<br />
<br />
{{patch|Pine.GSO.4.64.0809152349440.19910@westnet.com|Add default_val to pg_settings|status=Committed 2008-10-06|Greg Smith|reviewers=Simon Riggs,Magnus Hagander}}<br />
<br />
{{patch|20081016102603.897D.52131E4D@oss.ntt.co.jp|Noisy _dosmaperror|status=Committed 2008-10-16|Takahiro Itagaki|reviewers=Tom Lane}}<br />
<br />
{{patch|b4e5ce320810151918g2acf69ebh9f80f4f2e1c203a0@mail.gmail.com|Memory leak on hashed agg rescan|status=Committed 2008-10-16|Neil Conway|reviewers=Tom Lane}}<br />
{{review|10455.1224160007@sss.pgh.pa.us|Tom Lane|move some logic to separate function}}<br />
<br />
{{patch|1223383838.4747.154.camel@ebony.2ndQuadrant|Atomic subtransaction commit|status=Committed 2008-10-20|Simon Riggs|reviewers=Alvaro Herrera}} <br />
<br />
{{patch|3327.1224535092@sss.pgh.pa.us|add placeholder variables to planner|status=Committed 2008-10-22|Tom Lane}}<br />
<br />
{{patch|48E271C5.7010907@hagander.net|pg_hba options parsing|status=Committed 2008-10-23|Magnus Hagander|reviewers=Bruce Momjian}}<br />
{{comment|Robert Haas|{{messageLink|48F0DE8B.8030004@hagander.net|updated patch}}}}<br />
<br />
{{patch|48FC3994.8040809@hagander.net|libpq ssl -> clear fallback looses error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905D22D.9040001@hagander.net|better hba parsing error messages|status=Committed 2008-10-27|Magnus Hagander}}<br />
<br />
{{patch|4905A1DE.5030102@hagander.net|remove crypt authentication|status=Committed 2008-10-28|Magnus Hagander}}<br />
<br />
{{patch|4905F515.3020208@gmx.net|Unicode escapes in literals|status=Committed 2008-10-29|Peter Eisentraut}}<br />
<br />
{{CommitFestEndSection}}<br />
<br />
== Returned with Feedback ==<br />
{{CommitFestSectionNew}}<br />
<br />
{{CommitFestEndSection}}</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3104SqlMedConnectionManager2008-10-29T21:53:23Z<p>Martin.pihlak: </p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
Minimally we need:<br />
<br />
; connection lookup(name) : lookup server, FDW and user mapping. Call FDW for connection details.<br />
<br />
Additional functions maybe required for obtaining details about servers, user mappings and FDW:<br />
; server lookup(name) : Server details: TYPE, VERSION etc.<br />
<br />
; user mapping lookup(server) : User mapping details for the session user.<br />
<br />
; foreign data wrapper lookup(name) : Foreign data wrapper details.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
===Current implementation===<br />
<br />
<pre><br />
-- dummy wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'foo', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=foo}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='default';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 10, oid, '{user=bob,password=secret}'::text[] <br />
from pg_foreign_server where srvname='foo' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('foo');<br />
option | value <br />
----------+--------<br />
host | /tmp<br />
port | 6543<br />
dbname | foo<br />
user | bob<br />
password | secret<br />
(5 rows)<br />
<br />
Time: 0.990 ms<br />
<br />
-- pgsql wrapper<br />
insert into pg_catalog.pg_foreign_server <br />
select 'bar', 2200, 10, oid, null, '{host=/tmp,port=6543,dbname=test2}'::text[]<br />
from pg_foreign_data_wrapper where fdwname='pgsql';<br />
<br />
insert into pg_catalog.pg_foreign_user_mapping <br />
select 0, oid, '{user=alice,password=public}'::text[] <br />
from pg_foreign_server where srvname='bar' limit 1;<br />
<br />
template1=# select * from pg_get_remote_connection_info('bar');<br />
option | value <br />
------------+-------------------------------------------------------------<br />
datasource | host=/tmp port=6543 dbname=test2 user=alice password=public<br />
(1 row)<br />
<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql200n.zip SQL:2008 standard]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=User:Martin.pihlak&diff=3102User:Martin.pihlak2008-10-29T16:33:06Z<p>Martin.pihlak: </p>
<hr />
<div>Testing and WIP<br />
* [[SqlMedConnectionManager|Design notes for SQL/MED compliant connection manager]]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=SqlMedConnectionManager&diff=3073SqlMedConnectionManager2008-10-27T13:47:21Z<p>Martin.pihlak: New page: <center>Under construction ...</center> ---- This design draft describes SQL/MED compatible connection manager for PostgreSQL. The initial approach is to provide only connection info manag...</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
Minimally we need:<br />
<br />
; connection lookup(name) : lookup server, FDW and user mapping. Call FDW for connection details.<br />
<br />
Additional functions maybe required for obtaining details about servers, user mappings and FDW:<br />
; server lookup(name) : Server details: TYPE, VERSION etc.<br />
<br />
; user mapping lookup(server) : User mapping details for the session user.<br />
<br />
; foreign data wrapper lookup(name) : Foreign data wrapper details.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql_2003_standard.zip Copy of the SQL/MED standard draft]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=User:Martin.pihlak/ConnectionManagerDraft&diff=3069User:Martin.pihlak/ConnectionManagerDraft2008-10-27T08:59:55Z<p>Martin.pihlak: /* Connection manager C API */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
Minimally we need:<br />
<br />
; connection lookup(name) : lookup server, FDW and user mapping. Call FDW for connection details.<br />
<br />
Additional functions maybe required for obtaining details about servers, user mappings and FDW:<br />
; server lookup(name) : Server details: TYPE, VERSION etc.<br />
<br />
; user mapping lookup(server) : User mapping details for the session user.<br />
<br />
; foreign data wrapper lookup(name) : Foreign data wrapper details.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql_2003_standard.zip Copy of the SQL/MED standard draft]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=User:Martin.pihlak/ConnectionManagerDraft&diff=3067User:Martin.pihlak/ConnectionManagerDraft2008-10-26T21:22:07Z<p>Martin.pihlak: /* Additional system catalogs */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_name_nsp_index" UNIQUE, btree (fdwname, fdwnamespace)<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_name_nsp_index" UNIQUE, btree (srvname, srvnamespace)<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesrvsysid_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
Minimally we need:<br />
<br />
; connection lookup(name) : lookup server, FDW and user mapping. Call FDW for connection details.<br />
<br />
Additional functions maybe required for obtaining details about servers, user mappings and FDW:<br />
; server lookup(name) : Server details: TYPE, VERSION etc.<br />
<br />
; user mapping lookup(name) : User mapping details.<br />
<br />
; foreign data wrapper lookup(name) : Foreign data wrapper details.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql_2003_standard.zip Copy of the SQL/MED standard draft]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=User:Martin.pihlak/ConnectionManagerDraft&diff=3066User:Martin.pihlak/ConnectionManagerDraft2008-10-26T21:21:17Z<p>Martin.pihlak: /* SQL API */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesysidsrv_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
Minimally we need:<br />
<br />
; connection lookup(name) : lookup server, FDW and user mapping. Call FDW for connection details.<br />
<br />
Additional functions maybe required for obtaining details about servers, user mappings and FDW:<br />
; server lookup(name) : Server details: TYPE, VERSION etc.<br />
<br />
; user mapping lookup(name) : User mapping details.<br />
<br />
; foreign data wrapper lookup(name) : Foreign data wrapper details.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
* The access to the function is initially limited to superusers only. The client modules that use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client module access can then be granted to ordinary users without leaking the connection details.<br />
* Should we consider <tt>search_path</tt> here, and how does pg_relation_size solve it?<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql_2003_standard.zip Copy of the SQL/MED standard draft]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=User:Martin.pihlak/ConnectionManagerDraft&diff=3062User:Martin.pihlak/ConnectionManagerDraft2008-10-25T15:49:27Z<p>Martin.pihlak: /* Additional system catalogs */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
Table "pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | <br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
Indexes:<br />
"pg_foreign_data_wrapper_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_server<br />
Table "pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
--------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
Indexes:<br />
"pg_foreign_server_oid_index" UNIQUE, btree (oid)<br />
<br />
template1=# \d pg_foreign_user_mapping<br />
Table "pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
------------+--------+-----------<br />
usesysid | oid | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
Indexes:<br />
"pg_foreign_user_mapping_usesysidsrv_index" UNIQUE, btree (usesrv, usesysid)<br />
<br />
</pre><br />
<br />
* In <tt>pg_foreign_user_mapping</tt> <tt>InvalidOid</tt> signifies PUBLIC access.<br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
Minimally we need:<br />
<br />
; connection lookup(name) : lookup server, FDW and user mapping. Call FDW for connection details.<br />
<br />
Additional functions maybe required for obtaining details about servers, user mappings and FDW:<br />
; server lookup(name) : Server details: TYPE, VERSION etc.<br />
<br />
; user mapping lookup(name) : User mapping details.<br />
<br />
; foreign data wrapper lookup(name) : Foreign data wrapper details.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
The access to the function is initially limited to superusers only. The client modules that <br />
use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client<br />
module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql_2003_standard.zip Copy of the SQL/MED standard draft]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=User:Martin.pihlak/ConnectionManagerDraft&diff=3060User:Martin.pihlak/ConnectionManagerDraft2008-10-24T13:50:01Z<p>Martin.pihlak: /* Connection manager C API */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
<br />
"pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | not null<br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
<br />
"pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
<br />
"pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
usename | name | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
<br />
</pre><br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
Provide connection manager interface for stored C functions, procedural language handlers, etc.<br />
Minimally we need:<br />
<br />
; connection lookup(name) : lookup server, FDW and user mapping. Call FDW for connection details.<br />
<br />
Additional functions maybe required for obtaining details about servers, user mappings and FDW:<br />
; server lookup(name) : Server details: TYPE, VERSION etc.<br />
<br />
; user mapping lookup(name) : User mapping details.<br />
<br />
; foreign data wrapper lookup(name) : Foreign data wrapper details.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
The access to the function is initially limited to superusers only. The client modules that <br />
use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client<br />
module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql_2003_standard.zip Copy of the SQL/MED standard draft]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=User:Martin.pihlak/ConnectionManagerDraft&diff=3059User:Martin.pihlak/ConnectionManagerDraft2008-10-24T13:27:19Z<p>Martin.pihlak: /* SQL syntax */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Since SQL/MED is not very widely adopted we can probably loosen some of the syntax rules and drop irrelevant clauses.<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
<br />
"pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | not null<br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
<br />
"pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
<br />
"pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
usename | name | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
<br />
</pre><br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
; server lookup(name) : look up servers by name.<br />
<br />
; user mapping lookup(server,user) : find mapping for the specified server and user.<br />
<br />
; foreign data wrapper lookup(name) : find foreign data wrapper.<br />
<br />
; connection lookup(server) : lookup fdw, and user mapping. call fdw for connection lookup.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
The access to the function is initially limited to superusers only. The client modules that <br />
use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client<br />
module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql_2003_standard.zip Copy of the SQL/MED standard draft]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=User:Martin.pihlak/ConnectionManagerDraft&diff=3058User:Martin.pihlak/ConnectionManagerDraft2008-10-24T13:23:02Z<p>Martin.pihlak: /* Design notes */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection information for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Typing "foreign data wrapper" can become tedious over time, can we use defaults or determine FDW from TYPE?<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
<br />
"pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | not null<br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
<br />
"pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
<br />
"pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
usename | name | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
<br />
</pre><br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
; server lookup(name) : look up servers by name.<br />
<br />
; user mapping lookup(server,user) : find mapping for the specified server and user.<br />
<br />
; foreign data wrapper lookup(name) : find foreign data wrapper.<br />
<br />
; connection lookup(server) : lookup fdw, and user mapping. call fdw for connection lookup.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
The access to the function is initially limited to superusers only. The client modules that <br />
use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client<br />
module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql_2003_standard.zip Copy of the SQL/MED standard draft]</div>Martin.pihlakhttps://wiki.postgresql.org/index.php?title=User:Martin.pihlak/ConnectionManagerDraft&diff=3055User:Martin.pihlak/ConnectionManagerDraft2008-10-24T13:03:22Z<p>Martin.pihlak: /* "default" FDW */</p>
<hr />
<div><center>Under construction ...</center><br />
----<br />
This design draft describes SQL/MED compatible connection manager for<br />
PostgreSQL. The initial approach is to provide only connection info management<br />
while leaving the actual connection handling to the client application.<br />
<br />
<br />
Why do we need this? <br />
* Built in repository for connection definitions - shareable between different modules.<br />
* Access control and logging for remote connections. <br />
* Improved control over who can actually create the connections.<br />
* Possibility for connection invalidation -- really useful for pl/proxy.<br />
* It is a prerequisite for further SQL/MED features.<br />
<br />
<br />
==Design notes==<br />
<br />
; server : The server describes the connection to the remote database. All of the connection details (such as hostname, port database name etc.) are provided via generic options.<br />
<br />
; user mapping : Maps the local database user to remote, possible remote credentials are provided in the generic options (probably contains sensitive data).<br />
<br />
; foreign data wrapper : The FDW handles all aspects of foreign data access -- this includes connection management, datatype conversion etc. Every foreign server is associated with exactly one FDW, but the FDW can be used to access several foreign servers.<br />
<br />
For the connection manager the FDW has mainly two responsibilites: one -- parsing<br />
and validating the generic options for server and user mapping, two -- providing<br />
connection lookup for the applications. <br />
<br />
The FDW-s are implemented as shared libraries that conform to a specific API.<br />
Eventually there will be a FDW for every connection type - dbi, oci, odbc, etc.<br />
Minimally we need at least one FDW that operates in pass-through mode -- options<br />
are not validated and connection lookup returns the raw server and user mapping. <br />
This would also serve as a boilerplate for future FDW implementations.<br />
<br />
===SQL syntax===<br />
<br />
<pre><br />
<foreign-data wrapper definition> ::=<br />
CREATE FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ LIBRARY <library name specification> ] <language clause> [ <generic options> ]<br />
<alter foreign-data wrapper statement> ::=<br />
ALTER FOREIGN DATA WRAPPER <foreign-data wrapper name><br />
[ <library name specification> ] [ <alter generic options> ]<br />
<drop foreign-data wrapper statement> ::=<br />
DROP FOREIGN DATA WRAPPER <foreign-data wrapper name> <drop behavior><br />
<br />
<foreign server definition> ::=<br />
CREATE SERVER <foreign server name><br />
[ TYPE <server type> ] [ VERSION <server version> ]<br />
FOREIGN DATA WRAPPER <foreign-data wrapper name> [ <generic options> ]<br />
<alter foreign server statement> ::=<br />
ALTER SERVER <foreign server name> [ <new version> ] [ <alter generic options> ]<br />
<drop foreign server statement> ::=<br />
DROP SERVER <foreign server name> <drop behavior><br />
<br />
<user mapping definition> ::=<br />
CREATE USER MAPPING FOR <authorization identifier | USER | CURRENT_USER | PUBLIC><br />
SERVER <foreign server name> [ <generic options> ]<br />
<alter user mapping statement> ::=<br />
ALTER USER MAPPING <specific or generic authorization identifier><br />
SERVER <foreign server name> <alter generic options><br />
<drop user mapping statement> ::=<br />
DROP USER MAPPING FOR <specific or generic authorization identifier><br />
SERVER <foreign server name><br />
</pre><br />
<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER pgsql LIBRARY 'pgsql_fdw';<br />
CREATE SERVER foo FOREIGN DATA WRAPPER pgsql OPTIONS (host 'remotehost', dbname 'remotedb');<br />
CREATE USER MAPPING FOR PUBLIC SERVER foo OPTIONS (username 'bob', password 'secret');<br />
</pre><br />
<br />
* Add <tt>foreign data wrapper</tt> and <tt>foreign server</tt> to the list of objects that have USAGE privilege.<br />
* Initially assume that only superusers can manipulate these objects, implement as grantable privileges if the need arises.<br />
* CREATE USER MAPPING leaves plaintext passwords in server log (but so does CREATE USER).<br />
* Typing "foreign data wrapper" can become tedious over time, can we use defaults or determine FDW from TYPE?<br />
<br />
===Additional system catalogs===<br />
<br />
Introduce system catalogs for fdw, server and user mapping. These are only visible<br />
to superuser. Provide views or access functions for ordinary users.<br />
<br />
<pre><br />
<br />
"pg_catalog.pg_foreign_data_wrapper"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
fdwname | name | not null<br />
fdwnamespace | oid | not null<br />
fdwowner | oid | not null<br />
fdwlibrary | text | not null<br />
fdwacl | aclitem[] | <br />
fdwoptions | text[] | <br />
<br />
"pg_catalog.pg_foreign_server"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
srvname | name | not null<br />
srvnamespace | oid | not null<br />
srvowner | oid | not null<br />
srvfdw | oid | not null<br />
srvacl | aclitem[] | <br />
srvoptions | text[] | <br />
<br />
"pg_catalog.pg_foreign_user_mapping"<br />
Column | Type | Modifiers <br />
----------------+-----------+-----------<br />
usename | name | not null<br />
usesrv | oid | not null<br />
useoptions | text[] | <br />
<br />
</pre><br />
<br />
=== Foreign data wrapper API ===<br />
<br />
; validate server option(key, value) : Validate the generic options for <tt>server</tt>.<br />
<br />
; validate user mapping option(key, value) : Validate the generic options for <tt>user mapping</tt>.<br />
<br />
; connection lookup(server, user) : Provide connection details for specified server and user mapping. <br />
<br />
For the dummy FDW the functions are mostly nops -- validation always succeeds and connection lookup returns<br />
the raw list of options for server and user mapping. This allows applications to use the connection manager<br />
without providing their own FDW library. The downside is that the application must be able to construct the<br />
connect strings from the raw options -- not always so straightforward.<br />
<br />
For more complicated FDW-s such as pgsql, the validation routines will check that the options provided to<br />
server are valid libpq conninfo parameters. Possibly also check that no user mapping related parameter appears<br />
in server options. Connection lookup will merge the server and user mapping options into single connect string.<br />
<br />
===Connection manager C API===<br />
<br />
; server lookup(name) : look up servers by name.<br />
<br />
; user mapping lookup(server,user) : find mapping for the specified server and user.<br />
<br />
; foreign data wrapper lookup(name) : find foreign data wrapper.<br />
<br />
; connection lookup(server) : lookup fdw, and user mapping. call fdw for connection lookup.<br />
<br />
===SQL API===<br />
For clients we provide a SQL accessible function that looks up server and user<br />
mapping and then call the FDW to obtain connection details. Something along the<br />
lines of:<br />
<br />
<pre><br />
# select * from pg_get_remote_connection_info('remotedb');<br />
<br />
key value<br />
----------- ----------------------------------------<br />
datasource dbname=remotedb host=remotehost user=...<br />
</pre><br />
<br />
Whereas other FDW-s, such as dbi might also include a seperate tuples for<br />
username and password:<br />
<br />
<pre><br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource dbi:mysql:database=sakila;host=localhost<br />
username root<br />
password salakala<br />
</pre><br />
<br />
The access to the function is initially limited to superusers only. The client modules that <br />
use it must also be owned by privileged user and defined as <tt>SECURITY DEFINER</tt>. Client<br />
module access can then be granted to ordinary users without leaking the connection details.<br />
<br />
===psql support===<br />
Need additional \dX commands for displaying remote connection information.<br />
<br />
===pg_dump support===<br />
* Need to be able to dump SERVER/USER MAPPING/FDW.<br />
* Ordinary users cannot dump connection definitions.<br />
* Be concerned about plaintext passwords in the dump.<br />
<br />
===Usage and statistics logging===<br />
Log access to remote connections.<br />
<br />
==Examples==<br />
<br />
===pgsql===<br />
<pre><br />
CREATE SERVER foodb FOREIGN DATA WRAPPPER pgsql<br />
OPTIONS (dbname='foodb', host='bar');<br />
<br />
CREATE USER MAPPING FOR public SERVER foodb<br />
OPTIONS (username='bob', password='salakala');<br />
<br />
alice# select * from pg_get_remote_connection_info('foodb');<br />
<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=foodb host=bar user=bob password=salakala<br />
(1 row)<br />
</pre><br />
<br />
===DBI and Excel===<br />
<pre><br />
CREATE FOREIGN DATA WRAPPER dbi LIBRARY 'dbi_wrapper' LANGUAGE C;<br />
<br />
CREATE SERVER dbdtest FOREIGN DATA WRAPPER dbi<br />
OPTIONS (<br />
datasource 'DBI:Excel:file=dbdtest.xls',<br />
attributes '{xl_vtbl => {TESTV => { ... } }}'<br />
);<br />
<br />
CREATE USER MAPPING FOR bob SERVER dbdtest<br />
OPTIONS (username NULL, password NULL);<br />
<br />
bob# select * from pg_get_remote_connection_info('dbdtest');<br />
<br />
key value<br />
----------- ------------------------------------------------------------<br />
datasource DBI:Excel:file=dbdtest.xls<br />
attributes {xl_vtbl => {TESTV => { ... } }}<br />
username NULL<br />
password NULL<br />
(4 rows)<br />
</pre><br />
<br />
===plproxy cluster===<br />
<pre><br />
CREATE SERVER userdb<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (cluster '{userdb_p0,userdb_p1}');<br />
<br />
CREATE SERVER userdb_p0<br />
FOREIGN DATA WRAPPER plproxy<br />
OPTIONS (dbname 'userdb_p0', host '127.0.0.1', port '6000')<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb');<br />
key value<br />
----------- ------------------------------------------------<br />
cluster {userdb_p0,userdb_p1}<br />
(1 row)<br />
<br />
bob# select * from pg_get_remote_connection_info('userdb_p0');<br />
key value<br />
----------- ------------------------------------------------<br />
datasource dbname=userdb_p0 host=127.0.0.1 port=600<br />
(1 row)<br />
<br />
</pre><br />
<br />
==="default" FDW===<br />
<pre><br />
CREATE SERVER bazdb FOREIGN DATA WRAPPER default<br />
OPTIONS (tnsname 'ORCL');<br />
<br />
CREATE USER MAPPING FOR bob SERVER bazdb OPTIONS (lusername 'scott', passw0rd 'tiger');<br />
<br />
bob# select * from pg_get_remote_connection_info('bazdb');<br />
key value<br />
----------- ------------------------------------------------<br />
tnsname ORCL<br />
lusername scott<br />
passw0rd tiger<br />
(3 rows)<br />
</pre><br />
<br />
==Issues==<br />
* A lot ...<br />
<br />
==Links==<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00314.php some discussions]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01025.php more discussions]<br />
* [http://www.wiscorp.com/sql_2003_standard.zip Copy of the SQL/MED standard draft]</div>Martin.pihlak