Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Oct 15, 2010 at 7:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Well, we cannot avoid changing pg_amop, or at least changing its
>> interpretation, because the current scheme simply can't represent
>> indexable operators that are used for anything except simple boolean
>> WHERE tests.
> What exactly do you mean by that?
> It has always seemed to me that the operator class mechanism is a
> complicated abstraction mechanism that actually adds only a very small
> amount of abstraction. Instead of referring to operators by name or
> OID we refer to them by a number that maps onto a name or OID.
Well, the amount of abstraction might be minimal, but the point is to be
able to understand which operators are related to an index and exactly
what the relationship is. There might be a better way to represent
"this operator acts as <= for btree int4 indexes" than "this operator
has strategy number 2 for btree int4 indexes", but it doesn't seem to me
that there's a lot of win available there. C code certainly finds it
more convenient to work with numbers than names, so I'm not excited
about replacing the strategy numbers with strategy names, if that's what
you're thinking.
> Perhaps we should think of pg_amop not so much
> as a way to tell the AM what to do, but just a way to tell it what
> operator is logically involved without relying on the name or OID.
I already think of it that way ...
>> Maybe we should think in terms of a side channel for Peter's patch
>> as well. I share your feeling that trying to propagate collation
>> the same way we now propagate typmod is a recipe for serious pain.
> I'm not sure what you're thinking of here.
I'm not either. I'm dissatisfied with the direction he's heading
because of the amount of code it's going to break, but I don't have a
better idea. It may well be impossible to have this feature without
breaking everything in sight. (And, if we are going to break everything
in sight, now would be a good time to think about changing typmod to
something more flexible than one int32.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
