2013-02-21 11:26:23 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* postgres_fdw.h
|
|
|
|
* Foreign-data wrapper for remote PostgreSQL servers
|
|
|
|
*
|
2016-01-02 19:33:40 +01:00
|
|
|
* Portions Copyright (c) 2012-2016, PostgreSQL Global Development Group
|
2013-02-21 11:26:23 +01:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* contrib/postgres_fdw/postgres_fdw.h
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef POSTGRES_FDW_H
|
|
|
|
#define POSTGRES_FDW_H
|
|
|
|
|
|
|
|
#include "foreign/foreign.h"
|
|
|
|
#include "lib/stringinfo.h"
|
|
|
|
#include "nodes/relation.h"
|
2014-11-15 01:48:53 +01:00
|
|
|
#include "utils/relcache.h"
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
#include "libpq-fe.h"
|
|
|
|
|
Allow postgres_fdw to ship extension funcs/operators for remote execution.
The user can whitelist specified extension(s) in the foreign server's
options, whereupon we will treat immutable functions and operators of those
extensions as candidates to be sent for remote execution.
Whitelisting an extension in this way basically promises that the extension
exists on the remote server and behaves compatibly with the local instance.
We have no way to prove that formally, so we have to rely on the user to
get it right. But this seems like something that people can usually get
right in practice.
We might in future allow functions and operators to be whitelisted
individually, but extension granularity is a very convenient special case,
so it got done first.
The patch as-committed lacks any regression tests, which is unfortunate,
but introducing dependencies on other extensions for testing purposes
would break "make installcheck" scenarios, which is worse. I have some
ideas about klugy ways around that, but it seems like material for a
separate patch. For the moment, leave the problem open.
Paul Ramsey, hacked up a bit more by me
2015-11-04 00:42:02 +01:00
|
|
|
/*
|
|
|
|
* FDW-specific planner information kept in RelOptInfo.fdw_private for a
|
|
|
|
* foreign table. This information is collected by postgresGetForeignRelSize.
|
|
|
|
*/
|
|
|
|
typedef struct PgFdwRelationInfo
|
|
|
|
{
|
2016-02-09 20:00:50 +01:00
|
|
|
/*
|
|
|
|
* True means that the relation can be pushed down. Always true for simple
|
|
|
|
* foreign scan.
|
|
|
|
*/
|
|
|
|
bool pushdown_safe;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Restriction clauses, divided into safe and unsafe to pushdown subsets.
|
|
|
|
*
|
|
|
|
* For a base foreign relation this is a list of clauses along-with
|
|
|
|
* RestrictInfo wrapper. Keeping RestrictInfo wrapper helps while dividing
|
|
|
|
* scan_clauses in postgresGetForeignPlan into safe and unsafe subsets.
|
|
|
|
* Also it helps in estimating costs since RestrictInfo caches the
|
|
|
|
* selectivity and qual cost for the clause in it.
|
|
|
|
*
|
|
|
|
* For a join relation, however, they are part of otherclause list
|
|
|
|
* obtained from extract_actual_join_clauses, which strips RestrictInfo
|
|
|
|
* construct. So, for a join relation they are list of bare clauses.
|
|
|
|
*/
|
Allow postgres_fdw to ship extension funcs/operators for remote execution.
The user can whitelist specified extension(s) in the foreign server's
options, whereupon we will treat immutable functions and operators of those
extensions as candidates to be sent for remote execution.
Whitelisting an extension in this way basically promises that the extension
exists on the remote server and behaves compatibly with the local instance.
We have no way to prove that formally, so we have to rely on the user to
get it right. But this seems like something that people can usually get
right in practice.
We might in future allow functions and operators to be whitelisted
individually, but extension granularity is a very convenient special case,
so it got done first.
The patch as-committed lacks any regression tests, which is unfortunate,
but introducing dependencies on other extensions for testing purposes
would break "make installcheck" scenarios, which is worse. I have some
ideas about klugy ways around that, but it seems like material for a
separate patch. For the moment, leave the problem open.
Paul Ramsey, hacked up a bit more by me
2015-11-04 00:42:02 +01:00
|
|
|
List *remote_conds;
|
|
|
|
List *local_conds;
|
|
|
|
|
|
|
|
/* Bitmap of attr numbers we need to fetch from the remote server. */
|
|
|
|
Bitmapset *attrs_used;
|
|
|
|
|
|
|
|
/* Cost and selectivity of local_conds. */
|
|
|
|
QualCost local_conds_cost;
|
|
|
|
Selectivity local_conds_sel;
|
|
|
|
|
2016-02-09 20:00:50 +01:00
|
|
|
/* Selectivity of join conditions */
|
|
|
|
Selectivity joinclause_sel;
|
|
|
|
|
|
|
|
/* Estimated size and cost for a scan or join. */
|
Allow postgres_fdw to ship extension funcs/operators for remote execution.
The user can whitelist specified extension(s) in the foreign server's
options, whereupon we will treat immutable functions and operators of those
extensions as candidates to be sent for remote execution.
Whitelisting an extension in this way basically promises that the extension
exists on the remote server and behaves compatibly with the local instance.
We have no way to prove that formally, so we have to rely on the user to
get it right. But this seems like something that people can usually get
right in practice.
We might in future allow functions and operators to be whitelisted
individually, but extension granularity is a very convenient special case,
so it got done first.
The patch as-committed lacks any regression tests, which is unfortunate,
but introducing dependencies on other extensions for testing purposes
would break "make installcheck" scenarios, which is worse. I have some
ideas about klugy ways around that, but it seems like material for a
separate patch. For the moment, leave the problem open.
Paul Ramsey, hacked up a bit more by me
2015-11-04 00:42:02 +01:00
|
|
|
double rows;
|
|
|
|
int width;
|
|
|
|
Cost startup_cost;
|
|
|
|
Cost total_cost;
|
2016-02-09 20:00:50 +01:00
|
|
|
/* Costs excluding costs for transferring data from the foreign server */
|
|
|
|
Cost rel_startup_cost;
|
|
|
|
Cost rel_total_cost;
|
Allow postgres_fdw to ship extension funcs/operators for remote execution.
The user can whitelist specified extension(s) in the foreign server's
options, whereupon we will treat immutable functions and operators of those
extensions as candidates to be sent for remote execution.
Whitelisting an extension in this way basically promises that the extension
exists on the remote server and behaves compatibly with the local instance.
We have no way to prove that formally, so we have to rely on the user to
get it right. But this seems like something that people can usually get
right in practice.
We might in future allow functions and operators to be whitelisted
individually, but extension granularity is a very convenient special case,
so it got done first.
The patch as-committed lacks any regression tests, which is unfortunate,
but introducing dependencies on other extensions for testing purposes
would break "make installcheck" scenarios, which is worse. I have some
ideas about klugy ways around that, but it seems like material for a
separate patch. For the moment, leave the problem open.
Paul Ramsey, hacked up a bit more by me
2015-11-04 00:42:02 +01:00
|
|
|
|
|
|
|
/* Options extracted from catalogs. */
|
|
|
|
bool use_remote_estimate;
|
|
|
|
Cost fdw_startup_cost;
|
|
|
|
Cost fdw_tuple_cost;
|
|
|
|
List *shippable_extensions; /* OIDs of whitelisted extensions */
|
|
|
|
|
|
|
|
/* Cached catalog information. */
|
|
|
|
ForeignTable *table;
|
|
|
|
ForeignServer *server;
|
|
|
|
UserMapping *user; /* only set in use_remote_estimate mode */
|
2016-02-03 15:01:59 +01:00
|
|
|
|
|
|
|
int fetch_size; /* fetch size for this remote table */
|
2016-02-09 20:00:50 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Name of the relation while EXPLAINing ForeignScan. It is used for join
|
|
|
|
* relations but is set for all relations. For join relation, the name
|
|
|
|
* indicates which foreign tables are being joined and the join type used.
|
|
|
|
*/
|
|
|
|
StringInfo relation_name;
|
|
|
|
|
|
|
|
/* Join information */
|
|
|
|
RelOptInfo *outerrel;
|
|
|
|
RelOptInfo *innerrel;
|
|
|
|
JoinType jointype;
|
|
|
|
List *joinclauses;
|
Allow postgres_fdw to ship extension funcs/operators for remote execution.
The user can whitelist specified extension(s) in the foreign server's
options, whereupon we will treat immutable functions and operators of those
extensions as candidates to be sent for remote execution.
Whitelisting an extension in this way basically promises that the extension
exists on the remote server and behaves compatibly with the local instance.
We have no way to prove that formally, so we have to rely on the user to
get it right. But this seems like something that people can usually get
right in practice.
We might in future allow functions and operators to be whitelisted
individually, but extension granularity is a very convenient special case,
so it got done first.
The patch as-committed lacks any regression tests, which is unfortunate,
but introducing dependencies on other extensions for testing purposes
would break "make installcheck" scenarios, which is worse. I have some
ideas about klugy ways around that, but it seems like material for a
separate patch. For the moment, leave the problem open.
Paul Ramsey, hacked up a bit more by me
2015-11-04 00:42:02 +01:00
|
|
|
} PgFdwRelationInfo;
|
|
|
|
|
2013-03-12 02:31:28 +01:00
|
|
|
/* in postgres_fdw.c */
|
|
|
|
extern int set_transmission_modes(void);
|
|
|
|
extern void reset_transmission_modes(int nestlevel);
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
/* in connection.c */
|
Avoid multiple foreign server connections when all use same user mapping.
Previously, postgres_fdw's connection cache was keyed by user OID and
server OID, but this can lead to multiple connections when it's not
really necessary. In particular, if all relevant users are mapped to
the public user mapping, then their connection options are certainly
the same, so one connection can be used for all of them.
While we're cleaning things up here, drop the "server" argument to
GetConnection(), which isn't really needed. This saves a few cycles
because callers no longer have to look this up; the function itself
does, but only when establishing a new connection, not when reusing
an existing one.
Ashutosh Bapat, with a few small changes by me.
2016-01-28 18:05:19 +01:00
|
|
|
extern PGconn *GetConnection(UserMapping *user, bool will_prep_stmt);
|
2013-02-21 11:26:23 +01:00
|
|
|
extern void ReleaseConnection(PGconn *conn);
|
|
|
|
extern unsigned int GetCursorNumber(PGconn *conn);
|
2013-03-10 19:14:53 +01:00
|
|
|
extern unsigned int GetPrepStmtNumber(PGconn *conn);
|
2014-02-04 03:30:02 +01:00
|
|
|
extern void pgfdw_report_error(int elevel, PGresult *res, PGconn *conn,
|
|
|
|
bool clear, const char *sql);
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
/* in option.c */
|
|
|
|
extern int ExtractConnectionOptions(List *defelems,
|
|
|
|
const char **keywords,
|
|
|
|
const char **values);
|
Allow postgres_fdw to ship extension funcs/operators for remote execution.
The user can whitelist specified extension(s) in the foreign server's
options, whereupon we will treat immutable functions and operators of those
extensions as candidates to be sent for remote execution.
Whitelisting an extension in this way basically promises that the extension
exists on the remote server and behaves compatibly with the local instance.
We have no way to prove that formally, so we have to rely on the user to
get it right. But this seems like something that people can usually get
right in practice.
We might in future allow functions and operators to be whitelisted
individually, but extension granularity is a very convenient special case,
so it got done first.
The patch as-committed lacks any regression tests, which is unfortunate,
but introducing dependencies on other extensions for testing purposes
would break "make installcheck" scenarios, which is worse. I have some
ideas about klugy ways around that, but it seems like material for a
separate patch. For the moment, leave the problem open.
Paul Ramsey, hacked up a bit more by me
2015-11-04 00:42:02 +01:00
|
|
|
extern List *ExtractExtensionList(const char *extensionsString,
|
|
|
|
bool warnOnMissing);
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
/* in deparse.c */
|
|
|
|
extern void classifyConditions(PlannerInfo *root,
|
|
|
|
RelOptInfo *baserel,
|
2014-03-07 22:35:58 +01:00
|
|
|
List *input_conds,
|
2013-02-21 11:26:23 +01:00
|
|
|
List **remote_conds,
|
2013-03-22 00:43:59 +01:00
|
|
|
List **local_conds);
|
|
|
|
extern bool is_foreign_expr(PlannerInfo *root,
|
|
|
|
RelOptInfo *baserel,
|
|
|
|
Expr *expr);
|
2013-03-12 23:58:13 +01:00
|
|
|
extern void deparseInsertSql(StringInfo buf, PlannerInfo *root,
|
|
|
|
Index rtindex, Relation rel,
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
List *targetAttrs, bool doNothing, List *returningList,
|
2013-03-22 05:31:11 +01:00
|
|
|
List **retrieved_attrs);
|
2013-03-12 23:58:13 +01:00
|
|
|
extern void deparseUpdateSql(StringInfo buf, PlannerInfo *root,
|
|
|
|
Index rtindex, Relation rel,
|
2013-03-22 05:31:11 +01:00
|
|
|
List *targetAttrs, List *returningList,
|
|
|
|
List **retrieved_attrs);
|
2013-03-12 23:58:13 +01:00
|
|
|
extern void deparseDeleteSql(StringInfo buf, PlannerInfo *root,
|
|
|
|
Index rtindex, Relation rel,
|
2013-03-22 05:31:11 +01:00
|
|
|
List *returningList,
|
|
|
|
List **retrieved_attrs);
|
2013-02-22 16:56:06 +01:00
|
|
|
extern void deparseAnalyzeSizeSql(StringInfo buf, Relation rel);
|
2013-03-22 05:31:11 +01:00
|
|
|
extern void deparseAnalyzeSql(StringInfo buf, Relation rel,
|
2013-05-29 22:58:43 +02:00
|
|
|
List **retrieved_attrs);
|
2014-07-10 21:01:31 +02:00
|
|
|
extern void deparseStringLiteral(StringInfo buf, const char *val);
|
2015-11-03 18:46:06 +01:00
|
|
|
extern Expr *find_em_expr_for_rel(EquivalenceClass *ec, RelOptInfo *rel);
|
2016-02-09 20:00:50 +01:00
|
|
|
extern List *build_tlist_to_deparse(RelOptInfo *foreign_rel);
|
2016-01-30 16:32:38 +01:00
|
|
|
extern void deparseSelectStmtForRel(StringInfo buf, PlannerInfo *root,
|
2016-02-09 20:00:50 +01:00
|
|
|
RelOptInfo *foreignrel, List *tlist,
|
|
|
|
List *remote_conds, List *pathkeys,
|
2016-01-30 16:32:38 +01:00
|
|
|
List **retrieved_attrs, List **params_list);
|
Allow postgres_fdw to ship extension funcs/operators for remote execution.
The user can whitelist specified extension(s) in the foreign server's
options, whereupon we will treat immutable functions and operators of those
extensions as candidates to be sent for remote execution.
Whitelisting an extension in this way basically promises that the extension
exists on the remote server and behaves compatibly with the local instance.
We have no way to prove that formally, so we have to rely on the user to
get it right. But this seems like something that people can usually get
right in practice.
We might in future allow functions and operators to be whitelisted
individually, but extension granularity is a very convenient special case,
so it got done first.
The patch as-committed lacks any regression tests, which is unfortunate,
but introducing dependencies on other extensions for testing purposes
would break "make installcheck" scenarios, which is worse. I have some
ideas about klugy ways around that, but it seems like material for a
separate patch. For the moment, leave the problem open.
Paul Ramsey, hacked up a bit more by me
2015-11-04 00:42:02 +01:00
|
|
|
|
|
|
|
/* in shippable.c */
|
|
|
|
extern bool is_builtin(Oid objectId);
|
|
|
|
extern bool is_shippable(Oid objectId, Oid classId, PgFdwRelationInfo *fpinfo);
|
2016-02-09 20:00:50 +01:00
|
|
|
extern const char *get_jointype_name(JoinType jointype);
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
#endif /* POSTGRES_FDW_H */
|