Re: [v9.3] writable foreign tables - Mailing list pgsql-hackers

From Albe Laurenz
Subject Re: [v9.3] writable foreign tables
Date
Msg-id D960CB61B694CF459DCFB4B0128514C208B882AF@exadv11.host.magwien.gv.at
Whole thread Raw
In response to Re: [v9.3] writable foreign tables  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.3] writable foreign tables
List 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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: WIP: index support for regexp search
Next
From: Przemek Lisowski
Date:
Subject: C-function, don't load external dll file