Obviously, you cannot create ordering in hash indexes, which is why nobody else does that either.
The list of relational database systems that offer asc/desc on btree index files is quite extensive. The list of relational database systems that do not offer it is: 1. PostgreSQL 2. ? It will make porting efforts more difficult and more confusing. If you have to write operators for dozens of index files it might scuttle the entire conversion project. Allowing custom operators allows exactly the same thing, I admit. But doing it a different way from everyone else is not a good idea. It seems trivial to do it. Every part of a CREATE INDEX statement is already non-standard to some extent because ANSI/ISO did not include it (a defect in my opinion). And every CREATE INDEX statement can look different than the others because the different index types have different purposes. I won't harp on it any more and if the core team is not interested that is not a problem with me. I can always do it myself if it annoys me enough. -----Original Message----- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 9:37 AM To: Dann Corbit Cc: pgsql-hackers Subject: Re: [HACKERS] Enhancement suggestion "Dann Corbit" <[EMAIL PROTECTED]> writes: > Allow ASC/DESC direction modifiers for index columns. We aren't going to do that, because it would be a meaningless concept for indexes that don't impose a linear sort order (which is to say, everything except btrees). The concept that actually fits into PG's index structure is to offer reverse-sort-order btree operator classes. Providing these as standard equipment for all the built-in datatypes has been discussed several times --- I'm not sure if it's mentioned in the TODO file but probably it should be. In the meantime you can cons up your own reverse order opclass with little effort beyond writing the one comparison function wrapper. See the archives for details. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
