Re: ctidscan as an example of custom-scan (Re: [v9.5] Custom Plan API)

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: hlinnaka <hlinnaka(at)iki(dot)fi>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: ctidscan as an example of custom-scan (Re: [v9.5] Custom Plan API)
Date: 2015-07-14 19:07:09
Message-ID: 20150714190709.GB2301@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:

> We don't have anything that currently tests the Custom Scan interface
> in the tree. The question is how important that is, and whether it's
> worth having what's basically a toy implementation just to demonstrate
> that the feature can work. If so, I think ctidscan is as good a toy
> example as any; in the interest of full disclosure, I was the one who
> suggested it in the first place. But I am not entirely sure it's a
> good idea to saddle ourselves with that maintenance effort. It would
> be a lot more interesting if we had an example that figured to be
> generally useful.

As a general principle, I think it's a good idea to have a module that's
mostly just a skeleton that guides people into writing something real to
use whatever API is being tested. It needs to be simple enough that not
much need to be deleted when writing the real thing, and complex enough
to cover the parts that need covering. If whatever replaces ctidscan is
too complex, it will not serve that purpose.

My guess is that something whose only purpose is to test the custom scan
interface for coverage purposes can be simpler than this module.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2015-07-14 19:40:40 Re: RLS fails to work with UPDATE ... WHERE CURRENT OF
Previous Message Peter Geoghegan 2015-07-14 18:52:34 Re: Could be improved point of UPSERT