On Sat, Feb 13, 2010 at 2:03 PM, Joshua Tolley <eggyknap@gmail.com> wrote:
> On Sat, Feb 13, 2010 at 01:31:44PM -0500, Robert Haas wrote:
>> On Sat, Feb 13, 2010 at 1:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > Teodor Sigaev <teodor@sigaev.ru> writes:
>> >> I see your point. May be it's better to introduce new system table? pg_amorderop
>> >> to store ordering operations for index.
>> >
>> > We could, but that approach doesn't scale to wanting more categories
>> > in the future --- you're essentially decreeing that every new category
>> > of opclass-associated operator will require a new system catalog,
>> > along with all the infrastructure needed for that. That guarantees
>> > that the temptation to take shortcuts will remain high.
>>
>> Yeah. PFA a patch to allow 5-key syscaches.
>
> (Realizing I'm a lurker in this conversation, and hoping not to ask irritating
> questions) Do we need to rename SearchSysCache et al. to SearchSysCache1,
> etc.? It seems to me that requires changes to all kinds of software without
> any real need. The four lines of PL/LOLCODE that inspired this thought aren't
> themselves a great burden, but when combined with everyone else using
> SearchSysCache already...
If we want to allow 5-key syscaches, we have to add an extra parameter
to SearchSysCache and friends. So everyone caller of SearchSysCache
is going to break. (Well, unless we instead leave SearchSysCache
alone and add SearchSysCacheExtended or similar; but that's not really
project style.)
The point of the macros is that if someone some day decides they want
to allow SIX-key syscaches, we don't have to break all those people
again; we can just update the macro definitions.
...Robert