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:tgl@sss.pgh.pa.us]
Sent: Wednesday, February 02, 2005 9:37 AM
To: Dann Corbit
Cc: pgsql-hackers
Subject: Re: [HACKERS] Enhancement suggestion
"Dann Corbit" <DCorbit@connx.com> 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
