mirror of
https://github.com/postgres/postgres.git
synced 2025-06-29 10:41:53 +03:00
Remove tabs after spaces in C comments
This was not changed in HEAD, but will be done later as part of a pgindent run. Future pgindent runs will also do this. Report by Tom Lane Backpatch through all supported branches, but not HEAD
This commit is contained in:
@ -46,7 +46,7 @@ typedef struct
|
||||
} DR_sqlfunction;
|
||||
|
||||
/*
|
||||
* We have an execution_state record for each query in a function. Each
|
||||
* We have an execution_state record for each query in a function. Each
|
||||
* record contains a plantree for its query. If the query is currently in
|
||||
* F_EXEC_RUN state then there's a QueryDesc too.
|
||||
*
|
||||
@ -465,7 +465,7 @@ sql_fn_resolve_param_name(SQLFunctionParseInfoPtr pinfo,
|
||||
* Set up the per-query execution_state records for a SQL function.
|
||||
*
|
||||
* The input is a List of Lists of parsed and rewritten, but not planned,
|
||||
* querytrees. The sublist structure denotes the original query boundaries.
|
||||
* querytrees. The sublist structure denotes the original query boundaries.
|
||||
*/
|
||||
static List *
|
||||
init_execution_state(List *queryTree_list,
|
||||
@ -589,7 +589,7 @@ init_sql_fcache(FmgrInfo *finfo, Oid collation, bool lazyEvalOK)
|
||||
bool isNull;
|
||||
|
||||
/*
|
||||
* Create memory context that holds all the SQLFunctionCache data. It
|
||||
* Create memory context that holds all the SQLFunctionCache data. It
|
||||
* must be a child of whatever context holds the FmgrInfo.
|
||||
*/
|
||||
fcontext = AllocSetContextCreate(finfo->fn_mcxt,
|
||||
@ -601,7 +601,7 @@ init_sql_fcache(FmgrInfo *finfo, Oid collation, bool lazyEvalOK)
|
||||
oldcontext = MemoryContextSwitchTo(fcontext);
|
||||
|
||||
/*
|
||||
* Create the struct proper, link it to fcontext and fn_extra. Once this
|
||||
* Create the struct proper, link it to fcontext and fn_extra. Once this
|
||||
* is done, we'll be able to recover the memory after failure, even if the
|
||||
* FmgrInfo is long-lived.
|
||||
*/
|
||||
@ -671,7 +671,7 @@ init_sql_fcache(FmgrInfo *finfo, Oid collation, bool lazyEvalOK)
|
||||
fcache->src = TextDatumGetCString(tmp);
|
||||
|
||||
/*
|
||||
* Parse and rewrite the queries in the function text. Use sublists to
|
||||
* Parse and rewrite the queries in the function text. Use sublists to
|
||||
* keep track of the original query boundaries. But we also build a
|
||||
* "flat" list of the rewritten queries to pass to check_sql_fn_retval.
|
||||
* This is because the last canSetTag query determines the result type
|
||||
@ -711,7 +711,7 @@ init_sql_fcache(FmgrInfo *finfo, Oid collation, bool lazyEvalOK)
|
||||
* any polymorphic arguments.
|
||||
*
|
||||
* Note: we set fcache->returnsTuple according to whether we are returning
|
||||
* the whole tuple result or just a single column. In the latter case we
|
||||
* the whole tuple result or just a single column. In the latter case we
|
||||
* clear returnsTuple because we need not act different from the scalar
|
||||
* result case, even if it's a rowtype column. (However, we have to force
|
||||
* lazy eval mode in that case; otherwise we'd need extra code to expand
|
||||
@ -943,7 +943,7 @@ postquel_get_single_result(TupleTableSlot *slot,
|
||||
/*
|
||||
* Set up to return the function value. For pass-by-reference datatypes,
|
||||
* be sure to allocate the result in resultcontext, not the current memory
|
||||
* context (which has query lifespan). We can't leave the data in the
|
||||
* context (which has query lifespan). We can't leave the data in the
|
||||
* TupleTableSlot because we intend to clear the slot before returning.
|
||||
*/
|
||||
oldcontext = MemoryContextSwitchTo(resultcontext);
|
||||
@ -1051,7 +1051,7 @@ fmgr_sql(PG_FUNCTION_ARGS)
|
||||
/*
|
||||
* Switch to context in which the fcache lives. This ensures that our
|
||||
* tuplestore etc will have sufficient lifetime. The sub-executor is
|
||||
* responsible for deleting per-tuple information. (XXX in the case of a
|
||||
* responsible for deleting per-tuple information. (XXX in the case of a
|
||||
* long-lived FmgrInfo, this policy represents more memory leakage, but
|
||||
* it's not entirely clear where to keep stuff instead.)
|
||||
*/
|
||||
@ -1105,7 +1105,7 @@ fmgr_sql(PG_FUNCTION_ARGS)
|
||||
* suspend execution before completion is if we are returning a row from a
|
||||
* lazily-evaluated SELECT. So, when first entering this loop, we'll
|
||||
* either start a new query (and push a fresh snapshot) or re-establish
|
||||
* the active snapshot from the existing query descriptor. If we need to
|
||||
* the active snapshot from the existing query descriptor. If we need to
|
||||
* start a new query in a subsequent execution of the loop, either we need
|
||||
* a fresh snapshot (and pushed_snapshot is false) or the existing
|
||||
* snapshot is on the active stack and we can just bump its command ID.
|
||||
@ -1161,7 +1161,7 @@ fmgr_sql(PG_FUNCTION_ARGS)
|
||||
* Break from loop if we didn't shut down (implying we got a
|
||||
* lazily-evaluated row). Otherwise we'll press on till the whole
|
||||
* function is done, relying on the tuplestore to keep hold of the
|
||||
* data to eventually be returned. This is necessary since an
|
||||
* data to eventually be returned. This is necessary since an
|
||||
* INSERT/UPDATE/DELETE RETURNING that sets the result might be
|
||||
* followed by additional rule-inserted commands, and we want to
|
||||
* finish doing all those commands before we return anything.
|
||||
@ -1183,7 +1183,7 @@ fmgr_sql(PG_FUNCTION_ARGS)
|
||||
|
||||
/*
|
||||
* Flush the current snapshot so that we will take a new one for
|
||||
* the new query list. This ensures that new snaps are taken at
|
||||
* the new query list. This ensures that new snaps are taken at
|
||||
* original-query boundaries, matching the behavior of interactive
|
||||
* execution.
|
||||
*/
|
||||
@ -1241,7 +1241,7 @@ fmgr_sql(PG_FUNCTION_ARGS)
|
||||
else if (fcache->lazyEval)
|
||||
{
|
||||
/*
|
||||
* We are done with a lazy evaluation. Clean up.
|
||||
* We are done with a lazy evaluation. Clean up.
|
||||
*/
|
||||
tuplestore_clear(fcache->tstore);
|
||||
|
||||
@ -1265,8 +1265,8 @@ fmgr_sql(PG_FUNCTION_ARGS)
|
||||
else
|
||||
{
|
||||
/*
|
||||
* We are done with a non-lazy evaluation. Return whatever is in
|
||||
* the tuplestore. (It is now caller's responsibility to free the
|
||||
* We are done with a non-lazy evaluation. Return whatever is in
|
||||
* the tuplestore. (It is now caller's responsibility to free the
|
||||
* tuplestore when done.)
|
||||
*/
|
||||
rsi->returnMode = SFRM_Materialize;
|
||||
@ -1378,7 +1378,7 @@ sql_exec_error_callback(void *arg)
|
||||
|
||||
/*
|
||||
* Try to determine where in the function we failed. If there is a query
|
||||
* with non-null QueryDesc, finger it. (We check this rather than looking
|
||||
* with non-null QueryDesc, finger it. (We check this rather than looking
|
||||
* for F_EXEC_RUN state, so that errors during ExecutorStart or
|
||||
* ExecutorEnd are blamed on the appropriate query; see postquel_start and
|
||||
* postquel_end.)
|
||||
@ -1670,7 +1670,7 @@ check_sql_fn_retval(Oid func_id, Oid rettype, List *queryTreeList,
|
||||
* the function that's calling it.
|
||||
*
|
||||
* XXX Note that if rettype is RECORD, the IsBinaryCoercible check
|
||||
* will succeed for any composite restype. For the moment we rely on
|
||||
* will succeed for any composite restype. For the moment we rely on
|
||||
* runtime type checking to catch any discrepancy, but it'd be nice to
|
||||
* do better at parse time.
|
||||
*/
|
||||
@ -1716,7 +1716,7 @@ check_sql_fn_retval(Oid func_id, Oid rettype, List *queryTreeList,
|
||||
/*
|
||||
* Verify that the targetlist matches the return tuple type. We scan
|
||||
* the non-deleted attributes to ensure that they match the datatypes
|
||||
* of the non-resjunk columns. For deleted attributes, insert NULL
|
||||
* of the non-resjunk columns. For deleted attributes, insert NULL
|
||||
* result columns if the caller asked for that.
|
||||
*/
|
||||
tupnatts = tupdesc->natts;
|
||||
|
Reference in New Issue
Block a user