[Postgres-xc-developers] Param handling refactoring - Part 1

[Amit K. <ami...@en...>]

There has been errors like :
"Cannot find parameter $4" or
"Bind supplies 4 parameters while Prepare needs 8 parameters" that we
have been getting for specific scenarios. These scenarios come up in
plpgsql functions. This is the root cause:

If PLpgSQL_datum.dtype is not a simple type (PLPGSQL_DTYPE_VAR), the
parameter types (ParamExternData.ptype) for such plpgsql functions are
not set until when the values are actually populated. Example of such
variables is record variable without %rowtype specification. The
ParamListInfo.paramFetch hook function is called when needed to fetch
the such parameter types. In the XC function
pgxc_set_remote_parameters(), we do not consider this, and we check
only the ParamExternData.ptype to see if parameters are present, and
end up with lesser parameters than the actual parameters, sometimes
even ending up with 0 parameter types.

During trigger support implementation, it was discovered that due to
this issue,
the NEW.field or OLD.field cannot be used directly in SQL statements.

Actually we don't even need parameter types to be set at plan time in
XC. We only need them at the BIND message. There, we can anyway infer
the types from the tuple descriptor. So the attached patch removes all
the places where parameter types are set, and derives them when the
BIND data row is built.

I have not touched the SetRemoteStatementName function in this patch.
There can be scenarios where user calls PREPARE using parameter types,
and in such cases it is better to use these parameters in
SetRemoteStatementName() being called from BuildCachedPlan with
non-NULL boundParams. Actually use of parameter types during PREPARE
and rebuilding cached plans etc will be dealt further after this one.
So, I haven't removed param types altogether.

We also need to know whether the parameters are supplied through
source data plan (DMLs) or they are external. So added a field
has_internal_params in RemoteQuery to make this difference explicit.
Data row and parameters types are built in a different manner for DMLs
and non-DMLs.

Moved the datarow generation function from execTuples.c to execRemote.c .

Regressions
-----------------

There is a parameter related error in plpgsql.sql test, which does not
occur now, so corrected the expected output. It still does not show
the exact output because of absence of trigger support.

Added new test xc_params.sql which would be further extended later.