Skip site navigation (1) Skip section navigation (2)

Re: Reverse-sort indexes and NULLS FIRST/LAST sorting

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Reverse-sort indexes and NULLS FIRST/LAST sorting
Date: 2007-01-02 14:47:06
Message-ID: 3207.1167749226@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> I'd like to see this implemented with more general collation support in 
> mind.

I'm really not prepared to buy into that, simply because it puts ICU or
some equivalent large chunk of new code into the critical path to finish
what I'm doing.  The fact that pathkeys will become structs will
probably make it easier to add collation later (adding another field to
the struct won't mean a wholesale notational change), but that doesn't
mean I have to do it now.

> The NULLS FIRST/LAST support, as well as ascending and descending 
> orderings would be special cases of the general collation and collation 
> conversion machinery.

That seems like a bad idea, because nulls first/last and asc/desc
ordering are valid concepts for all btree-indexable datatypes, whereas
collation is only meaningful for text.  Besides, that approach just
moves the bloat over from too-many-opclasses to too-many-collations; do
we really want to need four collation objects for each basic collation?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-01-02 15:00:24
Subject: Re: TODO: Add a GUC to control whether BEGIN inside
Previous:From: Tom LaneDate: 2007-01-02 14:37:34
Subject: Re: Reverse-sort indexes and NULLS FIRST/LAST sorting

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group