2011-02-20 06:17:18 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* fdwapi.h
|
|
|
|
* API for foreign-data wrappers
|
|
|
|
*
|
2013-01-01 23:15:01 +01:00
|
|
|
* Copyright (c) 2010-2013, PostgreSQL Global Development Group
|
2011-02-20 06:17:18 +01:00
|
|
|
*
|
|
|
|
* src/include/foreign/fdwapi.h
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef FDWAPI_H
|
|
|
|
#define FDWAPI_H
|
|
|
|
|
|
|
|
#include "nodes/execnodes.h"
|
|
|
|
#include "nodes/relation.h"
|
|
|
|
|
|
|
|
/* To avoid including explain.h here, reference ExplainState thus: */
|
|
|
|
struct ExplainState;
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Callback function signatures --- see fdwhandler.sgml for more info.
|
|
|
|
*/
|
|
|
|
|
Revise FDW planning API, again.
Further reflection shows that a single callback isn't very workable if we
desire to let FDWs generate multiple Paths, because that forces the FDW to
do all work necessary to generate a valid Plan node for each Path. Instead
split the former PlanForeignScan API into three steps: GetForeignRelSize,
GetForeignPaths, GetForeignPlan. We had already bit the bullet of breaking
the 9.1 FDW API for 9.2, so this shouldn't cause very much additional pain,
and it's substantially more flexible for complex FDWs.
Add an fdw_private field to RelOptInfo so that the new functions can save
state there rather than possibly having to recalculate information two or
three times.
In addition, we'd not thought through what would be needed to allow an FDW
to set up subexpressions of its choice for runtime execution. We could
treat ForeignScan.fdw_private as an executable expression but that seems
likely to break existing FDWs unnecessarily (in particular, it would
restrict the set of node types allowable in fdw_private to those supported
by expression_tree_walker). Instead, invent a separate field fdw_exprs
which will receive the postprocessing appropriate for expression trees.
(One field is enough since it can be a list of expressions; also, we assume
the corresponding expression state tree(s) will be held within fdw_state,
so we don't need to add anything to ForeignScanState.)
Per review of Hanada Shigeru's pgsql_fdw patch. We may need to tweak this
further as we continue to work on that patch, but to me it feels a lot
closer to being right now.
2012-03-09 18:48:48 +01:00
|
|
|
typedef void (*GetForeignRelSize_function) (PlannerInfo *root,
|
2012-06-10 21:20:04 +02:00
|
|
|
RelOptInfo *baserel,
|
|
|
|
Oid foreigntableid);
|
Revise FDW planning API, again.
Further reflection shows that a single callback isn't very workable if we
desire to let FDWs generate multiple Paths, because that forces the FDW to
do all work necessary to generate a valid Plan node for each Path. Instead
split the former PlanForeignScan API into three steps: GetForeignRelSize,
GetForeignPaths, GetForeignPlan. We had already bit the bullet of breaking
the 9.1 FDW API for 9.2, so this shouldn't cause very much additional pain,
and it's substantially more flexible for complex FDWs.
Add an fdw_private field to RelOptInfo so that the new functions can save
state there rather than possibly having to recalculate information two or
three times.
In addition, we'd not thought through what would be needed to allow an FDW
to set up subexpressions of its choice for runtime execution. We could
treat ForeignScan.fdw_private as an executable expression but that seems
likely to break existing FDWs unnecessarily (in particular, it would
restrict the set of node types allowable in fdw_private to those supported
by expression_tree_walker). Instead, invent a separate field fdw_exprs
which will receive the postprocessing appropriate for expression trees.
(One field is enough since it can be a list of expressions; also, we assume
the corresponding expression state tree(s) will be held within fdw_state,
so we don't need to add anything to ForeignScanState.)
Per review of Hanada Shigeru's pgsql_fdw patch. We may need to tweak this
further as we continue to work on that patch, but to me it feels a lot
closer to being right now.
2012-03-09 18:48:48 +01:00
|
|
|
|
|
|
|
typedef void (*GetForeignPaths_function) (PlannerInfo *root,
|
2012-06-10 21:20:04 +02:00
|
|
|
RelOptInfo *baserel,
|
|
|
|
Oid foreigntableid);
|
Revise FDW planning API, again.
Further reflection shows that a single callback isn't very workable if we
desire to let FDWs generate multiple Paths, because that forces the FDW to
do all work necessary to generate a valid Plan node for each Path. Instead
split the former PlanForeignScan API into three steps: GetForeignRelSize,
GetForeignPaths, GetForeignPlan. We had already bit the bullet of breaking
the 9.1 FDW API for 9.2, so this shouldn't cause very much additional pain,
and it's substantially more flexible for complex FDWs.
Add an fdw_private field to RelOptInfo so that the new functions can save
state there rather than possibly having to recalculate information two or
three times.
In addition, we'd not thought through what would be needed to allow an FDW
to set up subexpressions of its choice for runtime execution. We could
treat ForeignScan.fdw_private as an executable expression but that seems
likely to break existing FDWs unnecessarily (in particular, it would
restrict the set of node types allowable in fdw_private to those supported
by expression_tree_walker). Instead, invent a separate field fdw_exprs
which will receive the postprocessing appropriate for expression trees.
(One field is enough since it can be a list of expressions; also, we assume
the corresponding expression state tree(s) will be held within fdw_state,
so we don't need to add anything to ForeignScanState.)
Per review of Hanada Shigeru's pgsql_fdw patch. We may need to tweak this
further as we continue to work on that patch, but to me it feels a lot
closer to being right now.
2012-03-09 18:48:48 +01:00
|
|
|
|
|
|
|
typedef ForeignScan *(*GetForeignPlan_function) (PlannerInfo *root,
|
2012-06-10 21:20:04 +02:00
|
|
|
RelOptInfo *baserel,
|
|
|
|
Oid foreigntableid,
|
|
|
|
ForeignPath *best_path,
|
|
|
|
List *tlist,
|
|
|
|
List *scan_clauses);
|
2011-02-20 06:17:18 +01:00
|
|
|
|
|
|
|
typedef void (*ExplainForeignScan_function) (ForeignScanState *node,
|
2011-04-10 17:42:00 +02:00
|
|
|
struct ExplainState *es);
|
2011-02-20 06:17:18 +01:00
|
|
|
|
|
|
|
typedef void (*BeginForeignScan_function) (ForeignScanState *node,
|
2011-04-10 17:42:00 +02:00
|
|
|
int eflags);
|
2011-02-20 06:17:18 +01:00
|
|
|
|
2011-04-10 17:42:00 +02:00
|
|
|
typedef TupleTableSlot *(*IterateForeignScan_function) (ForeignScanState *node);
|
2011-02-20 06:17:18 +01:00
|
|
|
|
|
|
|
typedef void (*ReScanForeignScan_function) (ForeignScanState *node);
|
|
|
|
|
|
|
|
typedef void (*EndForeignScan_function) (ForeignScanState *node);
|
|
|
|
|
2012-04-06 21:02:35 +02:00
|
|
|
typedef int (*AcquireSampleRowsFunc) (Relation relation, int elevel,
|
2012-06-10 21:20:04 +02:00
|
|
|
HeapTuple *rows, int targrows,
|
|
|
|
double *totalrows,
|
|
|
|
double *totaldeadrows);
|
2012-04-06 21:02:35 +02:00
|
|
|
|
2012-04-06 22:04:10 +02:00
|
|
|
typedef bool (*AnalyzeForeignTable_function) (Relation relation,
|
2012-06-10 21:20:04 +02:00
|
|
|
AcquireSampleRowsFunc *func,
|
|
|
|
BlockNumber *totalpages);
|
2011-02-20 06:17:18 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* FdwRoutine is the struct returned by a foreign-data wrapper's handler
|
|
|
|
* function. It provides pointers to the callback functions needed by the
|
|
|
|
* planner and executor.
|
|
|
|
*
|
2012-04-06 21:02:35 +02:00
|
|
|
* More function pointers are likely to be added in the future. Therefore
|
|
|
|
* it's recommended that the handler initialize the struct with
|
|
|
|
* makeNode(FdwRoutine) so that all fields are set to NULL. This will
|
|
|
|
* ensure that no fields are accidentally left undefined.
|
2011-02-20 06:17:18 +01:00
|
|
|
*/
|
|
|
|
typedef struct FdwRoutine
|
|
|
|
{
|
|
|
|
NodeTag type;
|
|
|
|
|
2012-04-06 21:02:35 +02:00
|
|
|
/*
|
|
|
|
* These functions are required.
|
|
|
|
*/
|
Revise FDW planning API, again.
Further reflection shows that a single callback isn't very workable if we
desire to let FDWs generate multiple Paths, because that forces the FDW to
do all work necessary to generate a valid Plan node for each Path. Instead
split the former PlanForeignScan API into three steps: GetForeignRelSize,
GetForeignPaths, GetForeignPlan. We had already bit the bullet of breaking
the 9.1 FDW API for 9.2, so this shouldn't cause very much additional pain,
and it's substantially more flexible for complex FDWs.
Add an fdw_private field to RelOptInfo so that the new functions can save
state there rather than possibly having to recalculate information two or
three times.
In addition, we'd not thought through what would be needed to allow an FDW
to set up subexpressions of its choice for runtime execution. We could
treat ForeignScan.fdw_private as an executable expression but that seems
likely to break existing FDWs unnecessarily (in particular, it would
restrict the set of node types allowable in fdw_private to those supported
by expression_tree_walker). Instead, invent a separate field fdw_exprs
which will receive the postprocessing appropriate for expression trees.
(One field is enough since it can be a list of expressions; also, we assume
the corresponding expression state tree(s) will be held within fdw_state,
so we don't need to add anything to ForeignScanState.)
Per review of Hanada Shigeru's pgsql_fdw patch. We may need to tweak this
further as we continue to work on that patch, but to me it feels a lot
closer to being right now.
2012-03-09 18:48:48 +01:00
|
|
|
GetForeignRelSize_function GetForeignRelSize;
|
|
|
|
GetForeignPaths_function GetForeignPaths;
|
|
|
|
GetForeignPlan_function GetForeignPlan;
|
2011-02-20 06:17:18 +01:00
|
|
|
ExplainForeignScan_function ExplainForeignScan;
|
|
|
|
BeginForeignScan_function BeginForeignScan;
|
|
|
|
IterateForeignScan_function IterateForeignScan;
|
|
|
|
ReScanForeignScan_function ReScanForeignScan;
|
|
|
|
EndForeignScan_function EndForeignScan;
|
2012-04-06 21:02:35 +02:00
|
|
|
|
|
|
|
/*
|
2012-06-10 21:20:04 +02:00
|
|
|
* These functions are optional. Set the pointer to NULL for any that are
|
|
|
|
* not provided.
|
2012-04-06 21:02:35 +02:00
|
|
|
*/
|
|
|
|
AnalyzeForeignTable_function AnalyzeForeignTable;
|
2011-02-20 06:17:18 +01:00
|
|
|
} FdwRoutine;
|
|
|
|
|
|
|
|
|
|
|
|
/* Functions in foreign/foreign.c */
|
|
|
|
extern FdwRoutine *GetFdwRoutine(Oid fdwhandler);
|
|
|
|
extern FdwRoutine *GetFdwRoutineByRelId(Oid relid);
|
|
|
|
|
|
|
|
#endif /* FDWAPI_H */
|