Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit5fd386b

Browse files
committed
Get rid of postgres_fdw's assumption that remote type OIDs match ours.
The only place we depended on that was in sending numeric type OIDs inPQexecParams; but we can replace that usage with explicitly castingeach Param symbol in the query string, so that the types are specifiedto the remote by name not OID. This makes no immediate difference butwill be essential if we ever hope to support use of non-builtin types.
1 parent6c4f666 commit5fd386b

File tree

3 files changed

+32
-13
lines changed

3 files changed

+32
-13
lines changed

‎contrib/postgres_fdw/deparse.c

Lines changed: 12 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -331,12 +331,10 @@ foreign_expr_walker(Node *node, foreign_expr_cxt *context)
331331
* function or type defined in the information_schema.
332332
*
333333
* Our constraints for dealing with types are tighter than they are for
334-
* functions or operators: we want to accept only types that are in pg_catalog
335-
* (else format_type might incorrectly fail to schema-qualify their names),
336-
* and we want to be sure that the remote server will use the same OID as
337-
* we do (since we must transmit a numeric type OID when passing a value of
338-
* the type as a query parameter). Both of these are reasons to reject
339-
* objects created post-bootstrap.
334+
* functions or operators: we want to accept only types that are in pg_catalog,
335+
* else format_type might incorrectly fail to schema-qualify their names.
336+
* (This could be fixed with some changes to format_type, but for now there's
337+
* no need.) Thus we must exclude information_schema types.
340338
*
341339
* XXX there is a problem with this, which is that the set of built-in
342340
* objects expands over time. Something that is built-in to us might not
@@ -794,12 +792,20 @@ deparseConst(StringInfo buf, Const *node, PlannerInfo *root)
794792
* We don't need to renumber the parameter ID, because the executor functions
795793
* in postgres_fdw.c preserve the numbering of PARAM_EXTERN Params.
796794
* (This might change soon.)
795+
*
796+
* Note: we label the Param's type explicitly rather than relying on
797+
* transmitting a numeric type OID in PQexecParams(). This allows us to
798+
* avoid assuming that types have the same OIDs on the remote side as they
799+
* do locally --- they need only have the same names.
797800
*/
798801
staticvoid
799802
deparseParam(StringInfobuf,Param*node,PlannerInfo*root)
800803
{
801804
Assert(node->paramkind==PARAM_EXTERN);
802805
appendStringInfo(buf,"$%d",node->paramid);
806+
appendStringInfo(buf,"::%s",
807+
format_type_with_typemod(node->paramtype,
808+
node->paramtypmod));
803809
}
804810

805811
/*

‎contrib/postgres_fdw/expected/postgres_fdw.out

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -558,11 +558,11 @@ EXPLAIN (VERBOSE, COSTS false) EXECUTE st4(1);
558558

559559
-- once we try it enough times, should switch to generic plan
560560
EXPLAIN (VERBOSE, COSTS false) EXECUTE st4(1);
561-
QUERY PLAN
562-
----------------------------------------------------------------------------------------------
561+
QUERY PLAN
562+
-------------------------------------------------------------------------------------------------------
563563
Foreign Scan on public.ft1 t1
564564
Output: c1, c2, c3, c4, c5, c6, c7, c8
565-
Remote SQL: SELECT "C 1", c2, c3, c4, c5, c6, c7, c8 FROM "S 1"."T 1" WHERE (("C 1" = $1))
565+
Remote SQL: SELECT "C 1", c2, c3, c4, c5, c6, c7, c8 FROM "S 1"."T 1" WHERE (("C 1" = $1::integer))
566566
(3 rows)
567567

568568
-- value of $1 should not be sent to remote
@@ -613,12 +613,12 @@ EXPLAIN (VERBOSE, COSTS false) EXECUTE st5('foo', 1);
613613
(4 rows)
614614

615615
EXPLAIN (VERBOSE, COSTS false) EXECUTE st5('foo', 1);
616-
QUERY PLAN
617-
----------------------------------------------------------------------------------------------
616+
QUERY PLAN
617+
-------------------------------------------------------------------------------------------------------
618618
Foreign Scan on public.ft1 t1
619619
Output: c1, c2, c3, c4, c5, c6, c7, c8
620620
Filter: (t1.c8 = $1)
621-
Remote SQL: SELECT "C 1", c2, c3, c4, c5, c6, c7, c8 FROM "S 1"."T 1" WHERE (("C 1" = $2))
621+
Remote SQL: SELECT "C 1", c2, c3, c4, c5, c6, c7, c8 FROM "S 1"."T 1" WHERE (("C 1" = $2::integer))
622622
(4 rows)
623623

624624
EXECUTE st5('foo', 1);

‎contrib/postgres_fdw/postgres_fdw.c

Lines changed: 14 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -901,11 +901,24 @@ create_cursor(ForeignScanState *node)
901901
if (!OidIsValid(prm->ptype)&&params->paramFetch!=NULL)
902902
params->paramFetch(params,paramno);
903903

904+
/*
905+
* Force the remote server to infer a type for this parameter.
906+
* Since we explicitly cast every parameter (see deparse.c), the
907+
* "inference" is trivial and will produce the desired result.
908+
* This allows us to avoid assuming that the remote server has the
909+
* same OIDs we do for the parameters' types.
910+
*
911+
* We'd not need to pass a type array to PQexecParams at all,
912+
* except that there may be unused holes in the array, which
913+
* will have to be filled with something or the remote server will
914+
* complain. We arbitrarily set them to INT4OID earlier.
915+
*/
916+
types[paramno-1]=InvalidOid;
917+
904918
/*
905919
* Get string representation of each parameter value by invoking
906920
* type-specific output function, unless the value is null.
907921
*/
908-
types[paramno-1]=prm->ptype;
909922
if (prm->isnull)
910923
values[paramno-1]=NULL;
911924
else

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp