On Jan 4, 2007, at 13:33 , Tom Lane wrote:
Another possible objection is that in the proposed CREATE INDEX syntax
index-column-id [ opclass-name ] [ DESC ] [ NULLS {FIRST|LAST} ]
DESC must be a fully reserved word else it can't be distinguished from
an opclass name. But guess what,
Michael Glaesemann [EMAIL PROTECTED] writes:
On Jan 4, 2007, at 13:33 , Tom Lane wrote:
index-column-id [ opclass-name ] [ DESC ] [ NULLS {FIRST|LAST} ]
DESC must be a fully reserved word else it can't be distinguished from
an opclass name. But guess what, it already is.
A point in favor
Martijn van Oosterhout kleptog@svana.org writes:
On Mon, Jan 01, 2007 at 05:53:35PM -0500, Tom Lane wrote:
One way we could handle this is to say that reverse-sort indexes are
implemented by adding explicit catalog entries for reverse-sort opclasses,
with no additions to the underlying btree
On Mon, Jan 01, 2007 at 05:53:35PM -0500, Tom Lane wrote:
The SQL2003 spec adds optional NULLS FIRST and NULLS LAST modifiers
for ORDER BY clauses. Teodor proposed an implementation here:
http://archives.postgresql.org/pgsql-patches/2006-12/msg00019.php
which I didn't care for at all:
I'd like to see this implemented with more general collation support in
mind.
In general, each index column can be ordered by one collation. A query
matching the index collation can use the index directly, a query asking
for another collation needs to convert. The trivial way to convert from
Martijn van Oosterhout kleptog@svana.org writes:
Issues which you havn't addressed are:
- Pathkeys: How is the forward/reverse/nulls first/last going to be
encoded in the pathkey?
I'm envisioning a struct with operator OID and null-ordering flag.
If we implement the explicit REVERSE variant
Heikki Linnakangas [EMAIL PROTECTED] 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
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] 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
