Re: Custom Scan APIs (Re: Custom Plan node)

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Jim Mlodgenski <jimmy76(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Custom Scan APIs (Re: Custom Plan node)
Date: 2014-04-15 14:56:51
Message-ID: 20140415145651.GE2556@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> A concrete example here is setrefs.c, whose responsibilities tend to
> change from release to release. I think if we committed custom-scan
> as is, we'd have great difficulty changing setrefs.c's transformations
> ever again, at least if we hoped to not break users of the custom-scan
> API. I'm not sure what the solution is --- but turning setrefs into
> a white box instead of a black box isn't it.

Yeah, this was my (general) complaint as well and the answer that I kept
getting back is "well, it's ok, you can still break it between major
releases and the custom scan users will just have to deal with it".

I'm a bit on the fence about that, itself, but the other half of that
coin is that we could end up with parts of the *core* code that think
it's ok to go pulling in these functions, once they're exposed, and that
could end up making things quite ugly and difficult to maintain going
forward.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-04-15 15:07:11 Re: Custom Scan APIs (Re: Custom Plan node)
Previous Message Tom Lane 2014-04-15 14:44:16 Re: Custom Scan APIs (Re: Custom Plan node)