There seems to be some behavior change in current CVS with respect to
gist and gin indexes on varchar[]. Some side effect of the tsearch2
merge?


\d search_pages
Table "public.search_pages"
Column | Type | Modifiers
-----------+---------------------+-----------
page_name | character varying |
cats | character varying[] |
Indexes:
"search_pages_page" UNIQUE, btree (page_name)

create index search_pages_cats on search_pages using gin (cats);
ERROR: missing support function 1 for attribute 1 of index "search_pages_cats"

create index search_pages_cats on search_pages using gist (cats);
ERROR: data type character varying[] has no default operator class
for access method "gist"
HINT: You must specify an operator class for the index or define a
default operator class for the data type.

This works fine in 8.2, for example:
\d search_pages
Table "public.search_pages"
Column | Type | Modifiers
-----------+---------------------+-----------
page_name | character varying |
cats | character varying[] |
Indexes:
"search_pages_page" UNIQUE, btree (page_name)
"search_pages_cats" gin (cats)

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

"Gregory Maxwell" <gmaxwell@gmail.com> writes:
> There seems to be some behavior change in current CVS with respect to
> gist and gin indexes on varchar[]. Some side effect of the tsearch2
> merge?

I think more likely I broke it during the opfamily rewrite :-(. Looks
like I left out entries for _varchar (and _cidr too) thinking that the
binary-compatible functions in the same opfamily for _text and _inet
would serve ... but they won't, because arrays are never really "binary
compatible" (you have to at least substitute the other element type
OID). Will fix.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly