Re: [v9.3] writable foreign tables
Albe Laurenz <laurenz.albe@wien.gv.at>
From: "Albe Laurenz" <laurenz.albe@wien.gv.at>
To: "Kohei KaiGai *EXTERN*" <kaigai@kaigai.gr.jp>
Cc: "Atri Sharma" <atri.jiit@gmail.com>, "Alexander Korotkov *EXTERN*" <aekorotkov@gmail.com>, "Tom Lane" <tgl@sss.pgh.pa.us>, "Robert Haas" <robertmhaas@gmail.com>, "PgHacker" <pgsql-hackers@postgresql.org>, "Shigeru Hanada" <shigeru.hanada@gmail.com>
Date: 2012-11-20T15:11:28Z
Lists: pgsql-hackers
Kohei KaiGai wrote:
> Probably, it is helpful to provide a helper function that fetches an
attribute-
> number of pseudo "rowid" column from the supplied targetlist.
> If we have GetPseudoRowidColumn() at foreign/foreign.c, the avove
> routine can be rewritten as:
>
> static AttrNumber
> fileGetForeignRelWidth(PlannerInfo *root,
> RelOptInfo *baserel,
> Relation foreignrel,
> bool inhparent, List
*targetList)
> {
> FileFdwPlanState *fdw_private;
> AttrNumber nattrs = RelationGetNumberOfAttributes(foreignrel);
> AttrNumber anum_rowid;
>
> fdw_private = palloc0(sizeof(FileFdwPlanState));
> anum_rowid = GetPseudoRowidColumn(..., targetList);
> if (anum_rowid > 0)
> {
> Assert(anum_rowid > nattrs);
> fdw_private->anum_rowid
> = makeDefElem("anum_rowid", (Node
*)makeInteger(anum_rowid));
> nattrs = anum_rowid;
> }
> baserel->fdw_private = fdw_private;
>
> return nattrs;
> }
>
> In case when FDW drive wants to push-down other target entry into
foreign-
> side, thus, it needs multiple pseudo-columns, it is decision of the
extension.
> In addition, it does not take API change in the future, if some more
additional
> pseudo-column is required by some other new features.
>
> How about your opinion?
I think that this is better than what I suggested.
Yours,
Laurenz Albe
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix postgres_fdw's issues with inconsistent interpretation of data values.
- cc3f281ffb0a 9.3.0 cited