On Tue, Nov 23, 2010 at 11:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> It would be the first, because simply assigning another strategy number
>>> only satisfies one of the unique constraints on pg_amop. To allow
>>> arbitrary flexibility here, we would have to include all components of
>>> the ordering specification in the unique constraint that's presently
>>> just (amopopr, amopfamily) and is proposed to become
>>> (amopopr, amopfamily, amoppurpose). I think that's an undue amount of
>>> complexity to support something that's most likely physically impossible
>>> from the index's standpoint anyway.
>
>> Or, you'd need to pass these details separately to the AM, which seems
>> like a more more flexible way of doing it.
>
> A more flexible way of doing what? The first requirement here is that
> the catalog entries provide sufficient information to determine the
> semantics. You can't just say "this opclass supports ordering", you
> have to specify what that ordering is. Punting to the index AM helps
> not at all, unless your proposal is to hard-wire this in GIST rather
> than in the core planner.
Eh, let's just do it the way you want to do it. It's probably going
to have to be redone the next time somebody wants to make an
enhancement in this area, but I guess it's going to be easy to do that
then than to figure where to go with it now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
