Re: pg_am.amstrategies should be 0 when not meaningful?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Subject: Re: pg_am.amstrategies should be 0 when not meaningful?
Date: 2006-12-18 15:40:16
Message-ID: 8825.1166456416@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
>> I propose that we should set pg_am.amstrategies to zero when the index
>> AM doesn't have a fixed interpretation of strategy numbers. This would
>> make it clearer that there's no intended upper bound. It would also

> Agreed. BTW, that also plays around possibility of grouping operator
> classes - since GIN/GiST hasn't fixed strategy numbers, they opclasses
> can not be unioned into group without extra agreement.

Sure, but a group has to have agreement on semantics anyway ---
agreement on operator numbering would be part of that.

BTW, I've been looking at the built-in GIN array opclasses and wondering
if we couldn't make them a group. The advantage is that we'd need only
one pg_amop entry for each of the anyarray operators that are common to
all those classes. But you could also see that as a disadvantage,
because if the operators are "loose" in the group then there's no clear
indication that the individual opclasses depend on them. OTOH all these
entries will be marked pinned in pg_depend and so are undroppable, so
that disadvantage is largely academic.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-12-18 15:43:35 Re: pg_restore fails with a custom backup file
Previous Message Albe Laurenz 2006-12-18 15:33:42 Re: unixware and --with-ldap