On Wed, Mar 11, 2015 at 3:48 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > The one problem with this 'combined' solution however is that CustomScan > requires scanrelid - a valid index into the range table. When injecting > the node directly above a Scan node, that seems to work just fine (just > use the same value), but on other places (e.g. above a join) that's not > possible :-( > > I see three options: > > (1) creating a fake range table entry in the planner_hook (but for > which relation to choose?) > > (2) reusing an existing range table entry (but which one?) > > (3) allowing CustomScan either without a valid index into a range > table (or maybe referencing join relations and such) > > The first two options seem quite ugly to me - fragile and error prone. > What about the third one? > > I realize this is probably a misuse of the CustomScan API, but it's the > best way to inject external nodes into the plan that I'm aware of. > > BTW: I know there's a custom-join patch in the current commitfest, but > I'd like to stress out I'm not trying to replace the join itself - I'd > like to inject a node below / above it.
I think you might want to have a look at the custom-join patch, because I think it adopts approach #3 from the list above, and it would be good to know whether that approach works for you. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
