Re: Simplifying pg_am representation of index sortability - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Simplifying pg_am representation of index sortability
Date
Msg-id 87wt3gg1m3.fsf@stark.xeocode.com
Whole thread Raw
In response to Simplifying pg_am representation of index sortability  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Simplifying pg_am representation of index sortability  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> So I'm thinking that the pg_am columns amorderstrategy and amdescorder are
> redundant and should be replaced with a simple boolean, "amcansort" perhaps.
> Any objections?

Any chance of getting rid of the remaining inter-operator relationship columns
in pg_operator? At least for operator with btree strategy numbers oprcom and
oprnegate can be deduced. I think you already got rid of the rest. They are
quite a pain when defining cross-data-type operators.

I guess it's tricky since there may be operators which have valid negators and
commutators but which don't get used by any btree operator class. Does
Postgres actually make use of the oprcom and oprnegate in that case? Could
they be used only for such operators to provide values for when they can't be
automatically deduced?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ECPG regression tests seem rather fundamentally broken
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Simplifying pg_am representation of index sortability