Re: Triaging the remaining open commitfest items

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Triaging the remaining open commitfest items
Date: 2015-05-16 00:26:38
Message-ID: 55568EBE.1010907@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/13/15 7:46 PM, Kouhei Kaigai wrote:
>>> * ctidscan as an example of custom-scan
>>> > >
>>> > >This basically hasn't gotten any attention, which may mean nobody cares
>>> > >enough to justify putting it in the tree. We need to either push it to
>>> > >next CF or reject altogether.
>> >
>> >Agreed. I was fine with never committing this. I don't think we have
>> >a requirement that every hook or bit of functionality we expose at the
>> >C level must have an example in core. But other people (you? Simon?)
>> >seemed to want a demonstration in the core repository. If that's
>> >still a priority, I am willing to work on it more for 9.6, but there
>> >is not time now.
>> >
> If no other people required it again, I don't think this module should
> be kept in core and also I'm not favor to push ctidscan to v9.6 development
> cycle. It intends to demonstrate custom-scan interface, however, it is
> not certain an example always needs to be in-core.

FWIW, having TIDGreaterOperator would be very useful for anyone trying
to un-bloat a table, so it'd be nice if this was at least available as a
PGXN extension.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2015-05-16 00:32:55 Re: trust authentication behavior
Previous Message Tom Lane 2015-05-15 23:51:40 Re: brin regression test intermittent failures