| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jan Urbański <wulczer(at)wulczer(dot)org> |
| Subject: | Re: review: FDW API |
| Date: | 2011-02-15 19:13:34 |
| Message-ID: | 28279.1297797214@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> As the patch stands, we have to do get_rel_relkind() in a couple of
> places in parse analysis and the planner to distinguish a foreign table
> from a regular one. As the patch stands, there's nothing in
> RangeTblEntry (which is what we have in transformLockingClause) or
> RelOptInfo (for set_plain_rel_pathlist) to directly distinguish them.
Hmm. I don't have a problem with adding relkind to the planner's
RelOptInfo, but it seems to me that if parse analysis needs to know
this, you have put functionality into parse analysis that does not
belong there.
(No, I haven't read the patch...)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2011-02-15 19:39:12 | Re: pl/python do not delete function arguments |
| Previous Message | Robert Haas | 2011-02-15 19:00:06 | Re: review: FDW API |