Horton
Menu

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

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Kouhei Kaigai <kaigai@ak.jp.nec.com>, PgHacker <pgsql-hackers@postgresql.org>, Kohei KaiGai <kaigai@kaigai.gr.jp>, Shigeru Hanada <shigeru.hanada@gmail.com>, Jim Mlodgenski <jimmy76@gmail.com>, Peter Eisentraut <peter_e@gmx.net>
Date: 2014-04-15T14:56:51Z
Lists: pgsql-hackers 
* Tom Lane (tgl@sss.pgh.pa.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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.