postgresql/src/include/executor/tablefunc.h

68 lines
2.8 KiB
C
Raw Normal View History

/*-------------------------------------------------------------------------
*
* tablefunc.h
* interface for TableFunc executor node
*
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* src/include/executor/tablefunc.h
*
*-------------------------------------------------------------------------
*/
#ifndef _TABLEFUNC_H
#define _TABLEFUNC_H
/* Forward-declare this to avoid including execnodes.h here */
struct TableFuncScanState;
/*
* TableFuncRoutine holds function pointers used for generating content of
* table-producer functions, such as XMLTABLE.
*
* InitBuilder initialize table builder private objects. The output tuple
* descriptor, input functions for the columns, and typioparams are passed
* from executor state.
*
* SetDoc is called to define the input document. The table builder may
* apply additional transformations not exposed outside the table builder
* context.
*
* SetNamespace is called to pass namespace declarations from the table
* expression. This function may be NULL if namespaces are not supported by
* the table builder. Namespaces must be given before setting the row and
* column filters. If the name is given as NULL, the entry shall be for the
* default namespace.
*
* SetRowFilter is called do define the row-generating filter, which shall be
* used to extract each row from the input document.
*
* SetColumnFilter is called once for each column, to define the column-
* generating filter for the given column.
*
* FetchRow shall be called repeatedly until it returns that no more rows are
* found in the document. On each invocation it shall set state in the table
* builder context such that each subsequent GetValue call returns the values
* for the indicated column for the row being processed.
*
* DestroyBuilder shall release all resources associated with a table builder
* context. It may be called either because all rows have been consumed, or
* because an error occurred while processing the table expression.
*/
typedef struct TableFuncRoutine
{
void (*InitOpaque) (struct TableFuncScanState *state, int natts);
void (*SetDocument) (struct TableFuncScanState *state, Datum value);
void (*SetNamespace) (struct TableFuncScanState *state, const char *name,
const char *uri);
void (*SetRowFilter) (struct TableFuncScanState *state, const char *path);
void (*SetColumnFilter) (struct TableFuncScanState *state,
const char *path, int colnum);
bool (*FetchRow) (struct TableFuncScanState *state);
Datum (*GetValue) (struct TableFuncScanState *state, int colnum,
2017-06-21 20:39:04 +02:00
Oid typid, int32 typmod, bool *isnull);
void (*DestroyOpaque) (struct TableFuncScanState *state);
} TableFuncRoutine;
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* _TABLEFUNC_H */