2013-02-21 11:26:23 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* option.c
|
2021-09-07 05:27:30 +02:00
|
|
|
* FDW and GUC option handling for postgres_fdw
|
2013-02-21 11:26:23 +01:00
|
|
|
*
|
2021-01-02 19:06:25 +01:00
|
|
|
* Portions Copyright (c) 2012-2021, PostgreSQL Global Development Group
|
2013-02-21 11:26:23 +01:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* contrib/postgres_fdw/option.c
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "access/reloptions.h"
|
|
|
|
#include "catalog/pg_foreign_server.h"
|
|
|
|
#include "catalog/pg_foreign_table.h"
|
|
|
|
#include "catalog/pg_user_mapping.h"
|
|
|
|
#include "commands/defrem.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
|
|
|
#include "commands/extension.h"
|
2019-10-23 05:56:22 +02:00
|
|
|
#include "postgres_fdw.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
|
|
|
#include "utils/builtins.h"
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
#include "utils/guc.h"
|
2017-01-21 02:29:53 +01:00
|
|
|
#include "utils/varlena.h"
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Describes the valid options for objects that this wrapper uses.
|
|
|
|
*/
|
|
|
|
typedef struct PgFdwOption
|
|
|
|
{
|
|
|
|
const char *keyword;
|
|
|
|
Oid optcontext; /* OID of catalog in which option may appear */
|
|
|
|
bool is_libpq_opt; /* true if it's used in libpq */
|
|
|
|
} PgFdwOption;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Valid options for postgres_fdw.
|
|
|
|
* Allocated and filled in InitPgFdwOptions.
|
|
|
|
*/
|
|
|
|
static PgFdwOption *postgres_fdw_options;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Valid options for libpq.
|
|
|
|
* Allocated and filled in InitPgFdwOptions.
|
|
|
|
*/
|
|
|
|
static PQconninfoOption *libpq_options;
|
|
|
|
|
2021-09-07 05:27:30 +02:00
|
|
|
/*
|
|
|
|
* GUC parameters
|
|
|
|
*/
|
|
|
|
char *pgfdw_application_name = NULL;
|
|
|
|
|
|
|
|
void _PG_init(void);
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
/*
|
|
|
|
* Helper functions
|
|
|
|
*/
|
|
|
|
static void InitPgFdwOptions(void);
|
|
|
|
static bool is_valid_option(const char *keyword, Oid context);
|
|
|
|
static bool is_libpq_option(const char *keyword);
|
|
|
|
|
2019-12-20 06:53:34 +01:00
|
|
|
#include "miscadmin.h"
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Validate the generic options given to a FOREIGN DATA WRAPPER, SERVER,
|
|
|
|
* USER MAPPING or FOREIGN TABLE that uses postgres_fdw.
|
|
|
|
*
|
|
|
|
* Raise an ERROR if the option or its value is considered invalid.
|
|
|
|
*/
|
|
|
|
PG_FUNCTION_INFO_V1(postgres_fdw_validator);
|
|
|
|
|
|
|
|
Datum
|
|
|
|
postgres_fdw_validator(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
List *options_list = untransformRelOptions(PG_GETARG_DATUM(0));
|
|
|
|
Oid catalog = PG_GETARG_OID(1);
|
|
|
|
ListCell *cell;
|
|
|
|
|
|
|
|
/* Build our options lists if we didn't yet. */
|
|
|
|
InitPgFdwOptions();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check that only options supported by postgres_fdw, and allowed for the
|
|
|
|
* current object type, are given.
|
|
|
|
*/
|
|
|
|
foreach(cell, options_list)
|
|
|
|
{
|
|
|
|
DefElem *def = (DefElem *) lfirst(cell);
|
|
|
|
|
|
|
|
if (!is_valid_option(def->defname, catalog))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Unknown option specified, complain about it. Provide a hint
|
|
|
|
* with list of valid options for the object.
|
|
|
|
*/
|
|
|
|
PgFdwOption *opt;
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
initStringInfo(&buf);
|
|
|
|
for (opt = postgres_fdw_options; opt->keyword; opt++)
|
|
|
|
{
|
|
|
|
if (catalog == opt->optcontext)
|
|
|
|
appendStringInfo(&buf, "%s%s", (buf.len > 0) ? ", " : "",
|
|
|
|
opt->keyword);
|
|
|
|
}
|
|
|
|
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FDW_INVALID_OPTION_NAME),
|
|
|
|
errmsg("invalid option \"%s\"", def->defname),
|
2021-10-26 17:46:52 +02:00
|
|
|
buf.len > 0
|
|
|
|
? errhint("Valid options in this context are: %s",
|
|
|
|
buf.data)
|
|
|
|
: errhint("There are no valid options in this context.")));
|
2013-02-21 11:26:23 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Validate option value, when we can do so without any context.
|
|
|
|
*/
|
2013-06-12 23:52:54 +02:00
|
|
|
if (strcmp(def->defname, "use_remote_estimate") == 0 ||
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
strcmp(def->defname, "updatable") == 0 ||
|
Allow TRUNCATE command to truncate foreign tables.
This commit introduces new foreign data wrapper API for TRUNCATE.
It extends TRUNCATE command so that it accepts foreign tables as
the targets to truncate and invokes that API. Also it extends postgres_fdw
so that it can issue TRUNCATE command to foreign servers, by adding
new routine for that TRUNCATE API.
The information about options specified in TRUNCATE command, e.g.,
ONLY, CACADE, etc is passed to FDW via API. The list of foreign tables to
truncate is also passed to FDW. FDW truncates the foreign data sources
that the passed foreign tables specify, based on those information.
For example, postgres_fdw constructs TRUNCATE command using them
and issues it to the foreign server.
For performance, TRUNCATE command invokes the FDW routine for
TRUNCATE once per foreign server that foreign tables to truncate belong to.
Author: Kazutaka Onishi, Kohei KaiGai, slightly modified by Fujii Masao
Reviewed-by: Bharath Rupireddy, Michael Paquier, Zhihong Yu, Alvaro Herrera, Stephen Frost, Ashutosh Bapat, Amit Langote, Daniel Gustafsson, Ibrar Ahmed, Fujii Masao
Discussion: https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com
Discussion: https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com
2021-04-08 13:56:08 +02:00
|
|
|
strcmp(def->defname, "truncatable") == 0 ||
|
2021-04-02 12:45:42 +02:00
|
|
|
strcmp(def->defname, "async_capable") == 0 ||
|
|
|
|
strcmp(def->defname, "keep_connections") == 0)
|
2013-02-21 11:26:23 +01:00
|
|
|
{
|
2013-06-12 23:52:54 +02:00
|
|
|
/* these accept only boolean values */
|
2013-02-21 11:26:23 +01:00
|
|
|
(void) defGetBoolean(def);
|
|
|
|
}
|
|
|
|
else if (strcmp(def->defname, "fdw_startup_cost") == 0 ||
|
|
|
|
strcmp(def->defname, "fdw_tuple_cost") == 0)
|
|
|
|
{
|
2021-07-27 18:20:16 +02:00
|
|
|
/*
|
|
|
|
* These must have a floating point value greater than or equal to
|
|
|
|
* zero.
|
|
|
|
*/
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
char *value;
|
|
|
|
double real_val;
|
|
|
|
bool is_parsed;
|
2013-02-21 11:26:23 +01:00
|
|
|
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
value = defGetString(def);
|
|
|
|
is_parsed = parse_real(value, &real_val, 0, NULL);
|
|
|
|
|
|
|
|
if (!is_parsed)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("invalid value for floating point option \"%s\": %s",
|
|
|
|
def->defname, value)));
|
|
|
|
|
|
|
|
if (real_val < 0)
|
2013-02-21 11:26:23 +01:00
|
|
|
ereport(ERROR,
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
2021-07-27 18:20:16 +02:00
|
|
|
errmsg("\"%s\" must be a floating point value greater than or equal to zero",
|
2013-02-21 11:26:23 +01:00
|
|
|
def->defname)));
|
|
|
|
}
|
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
|
|
|
else if (strcmp(def->defname, "extensions") == 0)
|
|
|
|
{
|
|
|
|
/* check list syntax, warn about uninstalled extensions */
|
|
|
|
(void) ExtractExtensionList(defGetString(def), true);
|
|
|
|
}
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
else if (strcmp(def->defname, "fetch_size") == 0 ||
|
|
|
|
strcmp(def->defname, "batch_size") == 0)
|
2016-02-03 15:01:59 +01:00
|
|
|
{
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
char *value;
|
|
|
|
int int_val;
|
|
|
|
bool is_parsed;
|
|
|
|
|
|
|
|
value = defGetString(def);
|
|
|
|
is_parsed = parse_int(value, &int_val, 0, NULL);
|
2016-02-03 15:01:59 +01:00
|
|
|
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
if (!is_parsed)
|
2016-02-03 15:01:59 +01:00
|
|
|
ereport(ERROR,
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("invalid value for integer option \"%s\": %s",
|
|
|
|
def->defname, value)));
|
2021-01-20 23:05:46 +01:00
|
|
|
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
if (int_val <= 0)
|
2021-01-20 23:05:46 +01:00
|
|
|
ereport(ERROR,
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
2021-07-27 18:20:16 +02:00
|
|
|
errmsg("\"%s\" must be an integer value greater than zero",
|
2021-01-20 23:05:46 +01:00
|
|
|
def->defname)));
|
|
|
|
}
|
2019-12-20 06:53:34 +01:00
|
|
|
else if (strcmp(def->defname, "password_required") == 0)
|
|
|
|
{
|
2020-05-14 19:06:38 +02:00
|
|
|
bool pw_required = defGetBoolean(def);
|
2019-12-20 06:53:34 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Only the superuser may set this option on a user mapping, or
|
|
|
|
* alter a user mapping on which this option is set. We allow a
|
2020-05-14 19:06:38 +02:00
|
|
|
* user to clear this option if it's set - in fact, we don't have
|
|
|
|
* a choice since we can't see the old mapping when validating an
|
2019-12-20 06:53:34 +01:00
|
|
|
* alter.
|
|
|
|
*/
|
|
|
|
if (!superuser() && !pw_required)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
|
|
|
errmsg("password_required=false is superuser-only"),
|
|
|
|
errhint("User mappings with the password_required option set to false may only be created or modified by the superuser")));
|
|
|
|
}
|
2020-01-13 08:38:09 +01:00
|
|
|
else if (strcmp(def->defname, "sslcert") == 0 ||
|
|
|
|
strcmp(def->defname, "sslkey") == 0)
|
|
|
|
{
|
|
|
|
/* similarly for sslcert / sslkey on user mapping */
|
|
|
|
if (catalog == UserMappingRelationId && !superuser())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
|
|
|
errmsg("sslcert and sslkey are superuser-only"),
|
|
|
|
errhint("User mappings with the sslcert or sslkey options set may only be created or modified by the superuser")));
|
|
|
|
}
|
2013-02-21 11:26:23 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
PG_RETURN_VOID();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize option lists.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
InitPgFdwOptions(void)
|
|
|
|
{
|
|
|
|
int num_libpq_opts;
|
|
|
|
PQconninfoOption *lopt;
|
|
|
|
PgFdwOption *popt;
|
|
|
|
|
|
|
|
/* non-libpq FDW-specific FDW options */
|
|
|
|
static const PgFdwOption non_libpq_options[] = {
|
|
|
|
{"schema_name", ForeignTableRelationId, false},
|
|
|
|
{"table_name", ForeignTableRelationId, false},
|
|
|
|
{"column_name", AttributeRelationId, false},
|
2013-02-23 18:20:48 +01:00
|
|
|
/* use_remote_estimate is available on both server and table */
|
|
|
|
{"use_remote_estimate", ForeignServerRelationId, false},
|
|
|
|
{"use_remote_estimate", ForeignTableRelationId, false},
|
2013-02-21 11:26:23 +01:00
|
|
|
/* cost factors */
|
|
|
|
{"fdw_startup_cost", ForeignServerRelationId, false},
|
|
|
|
{"fdw_tuple_cost", ForeignServerRelationId, false},
|
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
|
|
|
/* shippable extensions */
|
|
|
|
{"extensions", ForeignServerRelationId, false},
|
2013-06-12 23:52:54 +02:00
|
|
|
/* updatable is available on both server and table */
|
|
|
|
{"updatable", ForeignServerRelationId, false},
|
|
|
|
{"updatable", ForeignTableRelationId, false},
|
Allow TRUNCATE command to truncate foreign tables.
This commit introduces new foreign data wrapper API for TRUNCATE.
It extends TRUNCATE command so that it accepts foreign tables as
the targets to truncate and invokes that API. Also it extends postgres_fdw
so that it can issue TRUNCATE command to foreign servers, by adding
new routine for that TRUNCATE API.
The information about options specified in TRUNCATE command, e.g.,
ONLY, CACADE, etc is passed to FDW via API. The list of foreign tables to
truncate is also passed to FDW. FDW truncates the foreign data sources
that the passed foreign tables specify, based on those information.
For example, postgres_fdw constructs TRUNCATE command using them
and issues it to the foreign server.
For performance, TRUNCATE command invokes the FDW routine for
TRUNCATE once per foreign server that foreign tables to truncate belong to.
Author: Kazutaka Onishi, Kohei KaiGai, slightly modified by Fujii Masao
Reviewed-by: Bharath Rupireddy, Michael Paquier, Zhihong Yu, Alvaro Herrera, Stephen Frost, Ashutosh Bapat, Amit Langote, Daniel Gustafsson, Ibrar Ahmed, Fujii Masao
Discussion: https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com
Discussion: https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com
2021-04-08 13:56:08 +02:00
|
|
|
/* truncatable is available on both server and table */
|
|
|
|
{"truncatable", ForeignServerRelationId, false},
|
|
|
|
{"truncatable", ForeignTableRelationId, false},
|
2016-02-03 15:01:59 +01:00
|
|
|
/* fetch_size is available on both server and table */
|
|
|
|
{"fetch_size", ForeignServerRelationId, false},
|
|
|
|
{"fetch_size", ForeignTableRelationId, false},
|
2021-01-20 23:05:46 +01:00
|
|
|
/* batch_size is available on both server and table */
|
|
|
|
{"batch_size", ForeignServerRelationId, false},
|
|
|
|
{"batch_size", ForeignTableRelationId, false},
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
/* async_capable is available on both server and table */
|
|
|
|
{"async_capable", ForeignServerRelationId, false},
|
|
|
|
{"async_capable", ForeignTableRelationId, false},
|
2021-04-02 12:45:42 +02:00
|
|
|
{"keep_connections", ForeignServerRelationId, false},
|
2019-12-20 06:53:34 +01:00
|
|
|
{"password_required", UserMappingRelationId, false},
|
2020-05-14 19:06:38 +02:00
|
|
|
|
2020-01-09 09:09:54 +01:00
|
|
|
/*
|
|
|
|
* sslcert and sslkey are in fact libpq options, but we repeat them
|
2020-05-14 19:06:38 +02:00
|
|
|
* here to allow them to appear in both foreign server context (when
|
|
|
|
* we generate libpq options) and user mapping context (from here).
|
2020-01-09 09:09:54 +01:00
|
|
|
*/
|
|
|
|
{"sslcert", UserMappingRelationId, true},
|
|
|
|
{"sslkey", UserMappingRelationId, true},
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
{NULL, InvalidOid, false}
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Prevent redundant initialization. */
|
|
|
|
if (postgres_fdw_options)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get list of valid libpq options.
|
|
|
|
*
|
|
|
|
* To avoid unnecessary work, we get the list once and use it throughout
|
|
|
|
* the lifetime of this backend process. We don't need to care about
|
|
|
|
* memory context issues, because PQconndefaults allocates with malloc.
|
|
|
|
*/
|
|
|
|
libpq_options = PQconndefaults();
|
|
|
|
if (!libpq_options) /* assume reason for failure is OOM */
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FDW_OUT_OF_MEMORY),
|
|
|
|
errmsg("out of memory"),
|
2018-03-22 22:33:10 +01:00
|
|
|
errdetail("Could not get libpq's default connection options.")));
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
/* Count how many libpq options are available. */
|
|
|
|
num_libpq_opts = 0;
|
|
|
|
for (lopt = libpq_options; lopt->keyword; lopt++)
|
|
|
|
num_libpq_opts++;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct an array which consists of all valid options for
|
|
|
|
* postgres_fdw, by appending FDW-specific options to libpq options.
|
|
|
|
*
|
|
|
|
* We use plain malloc here to allocate postgres_fdw_options because it
|
|
|
|
* lives as long as the backend process does. Besides, keeping
|
|
|
|
* libpq_options in memory allows us to avoid copying every keyword
|
|
|
|
* string.
|
|
|
|
*/
|
|
|
|
postgres_fdw_options = (PgFdwOption *)
|
|
|
|
malloc(sizeof(PgFdwOption) * num_libpq_opts +
|
|
|
|
sizeof(non_libpq_options));
|
|
|
|
if (postgres_fdw_options == NULL)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FDW_OUT_OF_MEMORY),
|
|
|
|
errmsg("out of memory")));
|
|
|
|
|
|
|
|
popt = postgres_fdw_options;
|
|
|
|
for (lopt = libpq_options; lopt->keyword; lopt++)
|
|
|
|
{
|
|
|
|
/* Hide debug options, as well as settings we override internally. */
|
|
|
|
if (strchr(lopt->dispchar, 'D') ||
|
|
|
|
strcmp(lopt->keyword, "fallback_application_name") == 0 ||
|
|
|
|
strcmp(lopt->keyword, "client_encoding") == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* We don't have to copy keyword string, as described above. */
|
|
|
|
popt->keyword = lopt->keyword;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* "user" and any secret options are allowed only on user mappings.
|
|
|
|
* Everything else is a server option.
|
|
|
|
*/
|
|
|
|
if (strcmp(lopt->keyword, "user") == 0 || strchr(lopt->dispchar, '*'))
|
|
|
|
popt->optcontext = UserMappingRelationId;
|
|
|
|
else
|
|
|
|
popt->optcontext = ForeignServerRelationId;
|
|
|
|
popt->is_libpq_opt = true;
|
|
|
|
|
|
|
|
popt++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Append FDW-specific options and dummy terminator. */
|
|
|
|
memcpy(popt, non_libpq_options, sizeof(non_libpq_options));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether the given option is one of the valid postgres_fdw options.
|
|
|
|
* context is the Oid of the catalog holding the object the option is for.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
is_valid_option(const char *keyword, Oid context)
|
|
|
|
{
|
|
|
|
PgFdwOption *opt;
|
|
|
|
|
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
|
|
|
Assert(postgres_fdw_options); /* must be initialized already */
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
for (opt = postgres_fdw_options; opt->keyword; opt++)
|
|
|
|
{
|
|
|
|
if (context == opt->optcontext && strcmp(opt->keyword, keyword) == 0)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether the given option is one of the valid libpq options.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
is_libpq_option(const char *keyword)
|
|
|
|
{
|
|
|
|
PgFdwOption *opt;
|
|
|
|
|
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
|
|
|
Assert(postgres_fdw_options); /* must be initialized already */
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
for (opt = postgres_fdw_options; opt->keyword; opt++)
|
|
|
|
{
|
|
|
|
if (opt->is_libpq_opt && strcmp(opt->keyword, keyword) == 0)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Generate key-value arrays which include only libpq options from the
|
2014-05-06 18:12:18 +02:00
|
|
|
* given list (which can contain any kind of options). Caller must have
|
2013-02-21 11:26:23 +01:00
|
|
|
* allocated large-enough arrays. Returns number of options found.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
ExtractConnectionOptions(List *defelems, const char **keywords,
|
|
|
|
const char **values)
|
|
|
|
{
|
|
|
|
ListCell *lc;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Build our options lists if we didn't yet. */
|
|
|
|
InitPgFdwOptions();
|
|
|
|
|
|
|
|
i = 0;
|
|
|
|
foreach(lc, defelems)
|
|
|
|
{
|
|
|
|
DefElem *d = (DefElem *) lfirst(lc);
|
|
|
|
|
|
|
|
if (is_libpq_option(d->defname))
|
|
|
|
{
|
|
|
|
keywords[i] = d->defname;
|
|
|
|
values[i] = defGetString(d);
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return i;
|
|
|
|
}
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* Parse a comma-separated string and return a List of the OIDs of the
|
|
|
|
* extensions named in the string. If any names in the list cannot be
|
|
|
|
* found, report a warning if warnOnMissing is true, else just silently
|
|
|
|
* ignore them.
|
|
|
|
*/
|
|
|
|
List *
|
|
|
|
ExtractExtensionList(const char *extensionsString, bool warnOnMissing)
|
|
|
|
{
|
|
|
|
List *extensionOids = NIL;
|
|
|
|
List *extlist;
|
|
|
|
ListCell *lc;
|
|
|
|
|
|
|
|
/* SplitIdentifierString scribbles on its input, so pstrdup first */
|
|
|
|
if (!SplitIdentifierString(pstrdup(extensionsString), ',', &extlist))
|
|
|
|
{
|
|
|
|
/* syntax error in name list */
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("parameter \"%s\" must be a list of extension names",
|
|
|
|
"extensions")));
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach(lc, extlist)
|
|
|
|
{
|
|
|
|
const char *extension_name = (const char *) lfirst(lc);
|
|
|
|
Oid extension_oid = get_extension_oid(extension_name, true);
|
|
|
|
|
|
|
|
if (OidIsValid(extension_oid))
|
|
|
|
{
|
|
|
|
extensionOids = lappend_oid(extensionOids, extension_oid);
|
|
|
|
}
|
|
|
|
else if (warnOnMissing)
|
|
|
|
{
|
|
|
|
ereport(WARNING,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_OBJECT),
|
|
|
|
errmsg("extension \"%s\" is not installed",
|
|
|
|
extension_name)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
list_free(extlist);
|
|
|
|
return extensionOids;
|
|
|
|
}
|
2021-09-07 05:27:30 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Module load callback
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
_PG_init(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Unlike application_name GUC, don't set GUC_IS_NAME flag nor check_hook
|
|
|
|
* to allow postgres_fdw.application_name to be any string more than
|
|
|
|
* NAMEDATALEN characters and to include non-ASCII characters. Instead,
|
|
|
|
* remote server truncates application_name of remote connection to less
|
|
|
|
* than NAMEDATALEN and replaces any non-ASCII characters in it with a '?'
|
|
|
|
* character.
|
|
|
|
*/
|
|
|
|
DefineCustomStringVariable("postgres_fdw.application_name",
|
|
|
|
"Sets the application name to be used on the remote server.",
|
|
|
|
NULL,
|
|
|
|
&pgfdw_application_name,
|
|
|
|
NULL,
|
|
|
|
PGC_USERSET,
|
|
|
|
0,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
}
|