Why would you need it?
I can't to use unique index for like_op without setting opclass, because I
have to use czech locale. I can create second index, but then I have two
equal indexes. Example:
number | description
000102 blabla bla
000103 bbbb fooo
number: varchar primary key.
Sometimes I need search all values with one prefix ~ like '0001%'. That's
all.
> USING INDEX [TABLESPACE ..] [OPCLASS ..]
This is unworkable --- consider a table with more than one unique
constraint and/or multiple-column constraints.
I forgot (full syntax is):
CREATE TABLE ....
number varchar PRIMARY KEY USING OPCLAS varchar_pattern_ops,
...
I seem to recall someone proposing extending the syntax of the UNIQUE
constraints themselves, but there really isn't enough use-case to
justify it AFAICS. Especially not when you can always use CREATE UNIQUE
INDEX.
I can always use second unique index. But it's redundant. This problem is
related to using nonC locale.
Regards
Pavel Stehule
_________________________________________________________________
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
